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Abstract: 

This report documents analyses that were performed in support of Task #3 of Work Package #3 
(WP3), “ROA Impact on the NAS”. The purpose of the overall work package was to determine if 
there are any serious issues that would prevent or prohibit ROA’s flying in the NAS on a routine 
basis, and if so, what actions should be taken to address them. The purpose of Task #3 was to look at 
this problem from the perspective of data modeling and sharing. 

Specific areas of investigation were: 

ROA impact on the NAS from a data model and sharing perspective . Answer the questions: 

-A Will any ROAs be incapable of providing any required information to the ATC or other 
agents? 

-A Are there any latency issues? 

-A Will new types of information be required? 

-A Will ROAs have to add equipment to process data associated with potential new 
procedures or operations? 

NAS modernization . Analyze the data modeling and sharing aspects of proposed future changes to the 
NAS, and determine whether or not these are compatible with ROA operations. This includes, but is 
not necessarily limited to: 

-ANAS Architecture version 6, 

-A Operational Evolution Plan (OEP), 

-ATarget System Description (TSD), 

-A System Wide Information Management (SWIM) architecture. 

Enterprise architecture frameworks . Investigate the interoperability of information system 
architectures that were or might be produced using the enterprise architecture framework approach: 
-^Federal Enterprise Architecture Framework (FEAF) 

-A Department of Defense Architecture Framework (DODAF), formerly Command, Control, 
Communication, Computers for Information, Surveillance and Reconnaissance (C4ISR). 

Data schemas . Analyze and compare proposed data “schemas” being proposed by the US NAS and 
the European air traffic management systems. 


Status: 


SEIT-Approved 


Limitations on use: 

A major portion of the effort was devoted to development of the spreadsheet of information (voice 
and data) flows in the NAS. This was accomplished via several brainstorming sessions, considering 
that no such spreadsheet could be found in literature, at the desired high functional level. Note that, 
although quite a bit was accomplished in the construction of this spreadsheet, there is still some work 
left to make it complete and consistent. It could also benefit from a thorough review by domain 
experts (pilots and controllers, for example). 
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EXECUTIVE SUMMARY 

This report documents analyses that were performed in support of Task #3 of Work 
Package #3 (WP3), “ROA Impact on the NAS”. The purpose of the overall work package 
was to determine if there are any serious issues that would prevent or prohibit ROA’s 
flying in the NAS on a routine basis, and if so, what actions should be taken to address 
them. The purpose of Task #3 was to look at this problem from the perspective of data 
modeling and sharing. 

Specific areas of investigation were: 

ROA impact on the NAS from a data model and sharing perspective . Answer the 
questions: 

-> Will any ROAs be incapable of providing any required information to the ATC 
or other agents? 

-> Are there any latency issues? 

-> Will new types of information be required? 

-> Will ROAs have to add equipment to process data associated with potential 
new procedures or operations? 

NAS modernization . Analyze the data modeling and sharing aspects of proposed future 
changes to the NAS, and determine whether or not these are compatible with ROA 
operations. This includes, but is not necessarily limited to: 

->NAS Architecture version 6, 

Operational Evolution Plan (OEP), 

-> Target System Description (TSD), 

System Wide Information Management (SWIM) architecture. 

Enterprise architecture frameworks . Investigate the interoperability of information system 
architectures that were or might be produced using the enterprise architecture framework 
approach: 

Federal Enterprise Architecture Framework (FEAF) 

-^Department of Defense Architecture Framework (DODAF), formerly 
Command, Control, Communication, Computers for Information, Surveillance 
and Reconnaissance (C4ISR). 

Data schemas . Analyze and compare proposed data “schemas” being proposed by the US 
NAS and the European air traffic management systems. 

The table below summarizes the progress that was made (or not made) on these goals. 
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ROA Data Needs 
Impact 

Architecture 

Analysis 

Enterprise 

Architecture 

Framework 

Analysis 

US vs, European 
Data Schema 
Comparison 

Spreadsheet of data 
flows in the NAS 
was developed with 
ROA-specific 
impacts noted. 

Analyzed 
Administrator’s 
Flight Plan, NAS 
Architecture, OEP, 
TSD. Also a cursory 
look at SWIM. 

Thorough 
investigation into 
history and 
similarities & 
differences among 
enterprise 
architecture 
frameworks. 

Initial look only. 
Needs further 
investigation and 
consultation with 
domain experts. 


A major portion of the effort was devoted to development of the spreadsheet of 
information (voice and data) flows in the NAS. This was accomplished via several 
brainstorming sessions. We decided to construct our own since no such table could be 
found in the literature, at least at the desired high functional level. Note that, although 
quite a bit was accomplished in the construction of this spreadsheet, there is still some 
work left to make it complete and consistent. It could also benefit from a thorough review 
by domain experts (pilots and controllers, for example). 

The premise of this exercise was to establish what information flows currently exist, and 
to assess whether or not there are any implications for ROAs. The result was a list of 
several “heads up” items. Not all of these pose a significant problem. It is more a matter 
of raising awareness about potential problems before they do become a limit to 
operational capability. 

- Primary radar returns (ROA is too stealthy to register), 

- Secondary radar returns (equipage issue, i.e., will ROA carry transponder?), 

- Voice/data communications between the AVCS pilot and the ATC controller 
(latency), 

- Data communications between the AVCS pilot and the ROA (latency), 

- Weather awareness (configuration of AVCS compared to manned flight deck vis-a- 
vis weather displays), 

- Terrain and obstacle avoidance (equipage issue - will EGPWS be installed?) 

- Pilot reports (how to “feel” turbulence and “see” weather to report to ATC?), 

- Future navigation capabilities (equipage issue with respect to RNAV, RNP), 

- Collision avoidance (for example, TCAS is currently disallowed for ROAs in 
restricted airspace). 

- Equivalent level of safety (what new on-board and/or off-board systems, and hence 
new data flows, will be required) 

- Surface movement situational awareness (equipage issue - will ROAs have 
transponders to cooperate in multi-lateration-based surface position awareness 
procedures?). 
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The enterprise architecture framework task consumed the next largest portion of 
energy on this activity. The main conclusion was that these are frameworks, not 
actual architectures, and although they are used to develop architectures, they 
themselves cannot be judged as interoperable or not. Their methodologies can be 
compared, however. A comparison between the civilian Federal Enterprise 
Architecture Framework (FEAF) and the military Department of Defense 
Architecture Framework (DODAF) is provided in this document. It turns out that, 
although not identical, they have many similarities, as they are based on very similar 
notions that are encapsulated in the so-called Zachman framework. 

However, although the military has developed architectures using DODAF (or its 
predecessor, Command, Control, Communications, Computers Information 
Surveillance & Reconnaissance (C4ISR)), not much has been done on the civilian 
side with FEAF. Therefore, actual determination of interoperability of military and 
civilian architectures produced by these frameworks was not possible. 

Finally, some investigation into future NAS architectures (NAS Architecture V. 5, 
OEP V. 6, TSD, SWIM) and into data schema comparisons were made. The potential 
effects of new operational concepts on information flows were noted, but these are 
two areas that would benefit from more work. 
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1 INTRODUCTION 

This report documents the analyses that were performed in support of Task #3 of Work 
Package #3 (WP3), “ROA Impact on the NAS”. The purpose of the overall work package 
was to determine if there are any serious issues that would prevent or prohibit ROA’s 
from flying in the NAS on a routine basis, and if so, what actions should be taken to 
address them. The purpose of Task #3 was to look at this problem from the perspective of 
data modeling and sharing. 

For the reader who is unfamiliar with the National Airspace System (NAS), please refer 
to APPENDIX C: Basics of the NAS. 

1.1 Background 

Access 5 is a national project sponsored by NASA, with participation by the Federal 
Aviation Administration (FAA), Department of Defense (DoD), and industry, to 
introduce civil High Altitude, Long Endurance (HALE) ROA to routine flight in the 
NAS. Access 5 commenced in May 2004 and is slated to run for five or more years. 

The goal of Access 5 is to assist in the development of policies and procedures, 
demonstrate the enabling technologies, and identify infrastructure to promote a robust 
civil market for HALE ROA. Access 5 will address ROA airworthiness certification, 
flight operations, and crew certification. Project efforts will also include the development 
of appropriate standards, working where appropriate, through existing national standards 
groups. The project products are policy and procedure recommendations on ROA system 
airworthiness certification, ROA flight operations, ROA pilot certification, and 
appropriate standards. The project will identify mature technologies in several areas, 
including conflict avoidance and communications, and will also provide 
recommendations on maintenance for continued airworthiness, currency for pilots, and 
guidelines/processes for safe operation. 

Access 5 plans call for integrating HALE ROA into the NAS through a four-step process: 

Step 1: Routine operations of HALE ROA above Flight Level (FL) 400 (40,000 feet) 
with restrictions. 

Step 2: Routine operations above FL180 (18,000 feet) with restrictions. 

Step 3: Routine operations above FL180 and access to ROA designated airports with 
emergency landings in restricted areas. 

Step 4: Routine operations above FL180 and access to ROA designated airports, 
including emergency landings (i.e., true "file-and-fly"). 


1.2 Document Organization 

Section 1 describes the Access 5 project in order to provide context for the analysis in 
this document. 
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Section 2 outlines the goals, scope and approach of this activity. Four areas were chosen 
for investigation: information flows in the NAS, NAS modernization, data schemas, and 
enterprise architecture frameworks. 

Section 4 provides the results and conclusions in the four areas of investigation. Several 
areas of potential ROA-information flow interaction were identified. Data-related aspects 
of NAS modernization, data schemas and enterprise architecture frameworks are 
discussed. 

Links to the appendices can be found below. APPENDIX A: Data Flows in the NAS 
Spreadsheet contains the main product of this activity. APPENDIX F: References has 
hyperlinks to many Internet websites that were used to produce this document. 

APPENDIX A: Data (Data flows in the NAS together with associated function, 
network, people, timing and motivation) 

APPENDIX B: Current NAS Sensors and Systems and Data Attributes (Connects 
specific hardware to data traffic and format). 

APPENDIX C: Basics of the NAS (A primer on how the NAS works, from the FAA 
website) 

APPENDIX D: Definitions (Defines terms and acronyms used in this document) 
APPENDIX E: Acronyms 
APPENDIX F: References 

2 Goals and Approach 

2.1 Goals 

Specific areas of investigation were: 

ROA impact on the NAS from a data model and sharing perspective . Answer the 
questions: 

Will any ROAs be incapable of providing any required information to the ATC 
or other agents? 

Are there any latency issues? 

Will new types of information be required? 

Will ROAs have to add equipment to process data associated with potential 
new procedures or operations? 

NAS modernization . Analyze the data modeling and sharing aspects of proposed future 
changes to the NAS, and determine whether or not these are compatible with ROA 
operations. This includes, but is not necessarily limited to: 

->NAS Architecture version 6, 

Operational Evolution Plan (OEP), 

-^Target System Description (TSD), 
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System Wide Information Management (SWIM) architecture. 


Data schemas . Analyze and compare proposed data “schemas” being proposed by the US 
NAS and the European air traffic management systems. 

Enterprise architecture frameworks . Investigate the interoperability of information system 
architectures that were or might be produced using the enterprise architecture framework 
approach: 

-^Federal Enterprise Architecture Framework (FEAF) 

-^Department of Defense Architecture Framework (DODAF), formerly 
Command, Control, Communication, Computers for Information, Surveillance 
and Reconnaissance (C4ISR). 

2.2 Scope 

For the most part, the analysis of ROA impact on the NAS from the data perspective is 
confined to current operational procedures and technologies in the NAS. However, there 
was some consideration given to the possible ramifications from procedures or 
technologies that are part of the FAA’s plan for NAS modernization, such as Area 
Navigation (RNAV), Required Navigation Performance (RNP), and Automatic 
Dependent Surveillance-Dependent (ADS-B). 

The other analysis areas (NAS modernization, enterprise architecture frameworks, and 
data schemas) naturally involve discussion of the future information environment in the 
NAS. 

The geographical scope was confined to the US National Airspace System (NAS), except 
for the comparison of data schemas, since the direction of data definition and 
management standards is already being influenced by European developments. 

2.3 Approach 

An extensive literature search was performed in order to gather information on the data 
flows in the NAS, NAS information architectures present and future, enterprise 
architecture frameworks, and US and European work in data object standardization. The 
results of these four investigations are summarized below. 


3 Results of Investigation and Analyses 

3.1 Data Flows in the NAS 

Unfortunately, an existing description of data flows in the NAS from a high-level 
functional view was not found. As a result, a significant portion of the work on Task #3 
was directed to developing such a description. This effort involved many hours of brain- 
storming among domain experts in meetings, telecons, private phone calls and e-mails, 
and discussions with co-workers. The result can be seen in APPENDIX A: Data Flows in 
the NAS Spreadsheet. 

In this table, data items are organized into nine categories: 
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- Weather, 

Surveillance, 

Strategic Flight Management, 

Tactical Flight Management, 

Flight Control, 

Aeronautical, 

ATM Resource Management, 

Operator Flight Recording, and 
ATC Flight Recording. 

Associated with each data item are the attributes of 

• Function(s) that the data supports (what), 

• Sequence of system nodes the data flows through (how), 

• Transmission mode (also part of how), 

• People involved in the production, transmission or use of the data (who), 

• Automated systems that produce, process or use data (also part of who) 

• Timeliness of the data (when), and 

• Motivation for its use (why). 


Here is an example entry from the Flight Management table: 


Data 

Function 

Network 

(Flow) 

Transmission 

Mode 

People 

Automated 

Systems 

Time 

Motivation 

Remarks 

Flight 

object 

(flight 

profile, 

plan) 

Planning 

(commercial 

strategic) 

AOC <-> 

Service 

provider 

Telephone or 
electronic 

Flow 

planners, 

AOC 

Operator and 

HOST 

computers 

Pre- 
departure 
planning 
up to 
push- 
back 

clearance 

request 

Efficiency 

(service 

provider); 

Meet 

demand 

(airline) 

Flight object 
could be 
generated 
well in 
advance 
and 

populated 
as flight 
time 

approaches. 


Note that voice communications were treated as “data” for the purposes of this study. 
Voice messages were organized according to content or purpose, and placed in the 
appropriate data category, or categories. For example, pilot-controller communication 
involving clearances appears in both the Surveillance category and the Flight Control 
category. It appears in the Surveillance category because it helps increase situational 
awareness of other pilots through the “party-line” effect. It appears in the Flight Control 
category as well because it serves to refine, or perhaps modify, the ROA flight plan. 


Here as an entry from the Surveillance table: 
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ita 

Function 

Network 

(Flow) 

Trans- 

mission 

Mode 

People 

Automated 

Systems 

Time 

Motivation 

Remarks 

ntroller - 
ot 

arance 

mmun- 

tion 

Situational 

awareness 

Pilot(s) <--> 
Controller(s) 

VHF, UHF 

Pilots, 

controllers 

NA 

Seconds 
to minutes 

Safety (air 
vehicle) 

Other pilots listen 
in on "party line" 
for information on 
nearby aircraft 


Here is the corresponding entry from the Flight Control table: 


:a 

Function 

Network 

(Flow) 

Trans- 

mission 

Mode 

People 

Automated 

Systems 

Time 

Motivation 

Remarks 

troller - 
t 

ranee 

imun- 

ion 

Flight 

management; 

maintain 

separation 

Pilot(s) <--> 
Controller(s) 

VHF, UHF 

Pilots, 

controllers 

NA 

Seconds 
to minutes 

Safety (air 
vehicle) 

Pilots modify the 
flight path based 
on clearance 


(Note: Extensive tables linking data flows to hardware do exist. For example, see 
APPENDIX B: Current NAS Sensors and Systems and Data Attributes , a table lifted 
from Ref [4].) 

3.2 NAS modernization 

Using information provided by the FAA website, various initiatives under the NAS 
modernization plan (NAS Architecture Version 5, OEP Version 6, TSD, Administrator’s 
Flight Plan, and SWIM) were examined to assess their potential for promoting 
interoperability and a common operating picture for all agents in the system. 

None of the programs that were analyzed for this document discuss ROA’s in any detail. 
The best that could be done was to study the various modernization programs and look 
for any mention of information system architectures and data standards or sharing, and 
surmise if there would be any implications for ROAs. 

There is a wide range of detail in these initiatives. The Administrator’s Flight Plan is 
basically a set of goals. The NAS Architecture Version 5.0 is high level initiative which 
includes the more detailed Operational Evolution Plan (OEP) and the much more detailed 
Target System Description (TSD), which is designed to implement the RTCA operational 
concept for 2015. The System Wide Information Management (SWIM) is another 
initiative whose goal is develop a global information architecture that provides tailored 
information to all agents in a timely, efficient, safe and secure way. 
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3.2.1 FAA Administrator’s Flight Plan 2004-2008 

This is a declaration of high-level goals of FAA for the next four years in the areas of 
capacity, safety, international leadership and organizational excellence. Although some 
references are made to technologies such as ADS-B/TIS-B, NAV, RNP, and WAAS, 
there are no detailed discussions of information architectures that include data needs or 
formats. For more details, see Ref. [7]. 

3.2.2 NAS Architecture Version 5 

Architecture 5 is a comprehensive plan for improving the NAS and reaching the Target 
System Description (TSD). 

From Ref. [9]: 

“The NAS Architecture, the FAA Strategic Plan, the NAS Operation Evolution Plan 
(OEP), the NAS Capital Investment Plan (CIP) and the National Aviation Research Plan 
(NARP) are key NAS modernization plans. Closely linked, each serves a specific 
purpose. The NAS Architecture is the agency’s 15-year plan for modernization, 
supporting safety, security, and system efficiency goals. This plan establishes objectives 
and strategies for each goal and identifies related projects. The Architecture includes 
projections of all expenditures, including research, operations, F&E, and user investment. 
The FAA Strategic Plan, realized by the NAS Architecture, details FAA goals, 
establishes objectives and strategies for each, and identifies related projects. The OEP is 
the agency’s commitment to the aviation industry for the next 10 years, addressing 
capacity and demand issues. The OEP, a subset and refinement of the Architecture, 
includes all expenditures, and has moved from funding projection to commitment. The 
CIP is the agency’s 5-year F&E plan linked to FAA performance goals. The NARP 
describes FAA research plans, including those in partnership with other government 
agencies and private resources, for a 5-year period. These plans are consistent; they 
complement each other with increasing levels of detail relating to execution of FAA 
commitments.” 

3.2.3 OEP Version 6 

The following is taken from Ref. [8]: 

“The Operational Evolution Plan (OEP) is the Federal Aviation Administration (FAA) 
ten-year plan to increase the capacity and efficiency of the National Airspace System 
(NAS) while enhancing safety and security. The commitments and decisions in the OEP 
have emerged from a close collaboration with the entire aviation community including 
the airlines, cargo carriers, airports, manufacturers, general aviation, the Department of 
Defense (DOD) and the National Aeronautics and Space Administration (NASA). 

Modernizing the NAS is continuous, evolutionary and multi-faceted. The OEP is a 
"living" document that matures over time. The OEP only contains capacity and 
efficiency-related programs that can be accomplished in a ten-year timeframe and with 
each version the timeframe rolls forward one year. Updates may occur as decisions are 
made, risks are identified and mitigated, or research discovers new solutions to 
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operational problems. 

The OEP started as a business planning activity that accelerated during the summer 
delays and cancellations of August 2000 that were primarily due to dramatic increases in 
the number of people flying and particularly bad weather that summer. An FAA plan to 
address capacity and delay issues, developed in concert with the aviation community, was 
put in place in Spring 2001. FAA executives had also begun meeting in late 2000 to 
discuss a broader strategy to address capacity issues and to continue to get input from the 
aviation community. This OEP Executive Team identified four core problem areas, or 
quadrants: 

Arrival/Departure Rates 
En-Route Congestion 
Airport Weather Conditions 
En Route Severe Weather 


Technical teams developed "smart sheets" including key activities, decisions and 
milestones, for solutions in each of the four quadrants. A senior FAA executive was 
assigned then and continues to serve as the single Point of Delivery (POD), accountable 
along with a cross-agency support team for the delivery of products and services detailed 
in each smart sheet. 

Version 3.0 of the OEP was released on June 5, 2001, with an Executive Summary, 
program details and a chart assigning responsibilities to the FAA, airlines and airports. 
To oversee the implementation of the OEP, to manage the inter-dependencies of the 
solutions sets and to coordinate with the aviation community, the FAA established the 
Operational Evolution Staff in late Spring 2001 (202-385-4900). Version 4.0 was 
released on December 19, 2001, with expanded descriptions of milestones and major 
decisions. Version 5.0 was presented at an Industry Day on December 9, 2002, with 
greater detail of key activities and more alignment to accepted visions for the aerospace 
industry. Version 6.0 was presented at an Industry Day on December 8, 2003, with 
discussion centered around the establishment of the Air Traffic Organization, and how it 
and the OEP will move forward. Speakers at this Industry Day included the 
Administrator, Marion Blakey, and the ATO Chief Operating Officer, Russ Chew, as 
well as Vice President of Planning, Steve Brown, the PODs, and industry 
representatives.” 


3.2.4 Target System Description (TSD) 

The TSD is a view into the Architecture for the year 2015. TSD is based on the joint FAA 
and industry operational concept for planning and conducting flights with greater safety, 
flexibility, and efficiency. 

In Ref. [10]: 

“The Target System Description (TSD) provides a picture of the systems and facilities 
that will comprise the NAS Architecture when the current "National Airspace System 


16 


Concept of Operations and Vision for the Future of Aviation" (CONOPS) is achieved. A 
preview of the target implementations in the 2012 to 2015 timeframe will identify the 
extent of evolution of each air traffic service, capability, system, people, and support 
activities that will be in place to meet the TSD or CONOPS requirements.” 


3.2.5 SWIM 

The FAA definition of SWIM from Ref. [11] is: 

“Initiative to provide a common context for top-down, performance-oriented, secure 
integration and management of shared information assets across the global Air Traffic 
Management domain.” 

From Ref. [1]: 

“. . . the information object is the basic unit of information management within the 
SWIM. It is created by publisher members, disseminated to subscriber members and can 
be archived to support future queries. 

... a common data model in SWIM is a NAS-wide pre-defined and agreed upon 
definition of data structures (organized NAS data hierarchies) that make NAS 
information understandable by all SWIM members. A common data model agreed to by 
the entire SWIM user community is designed and information objects are derived based 
on the model. The structural information of the common data model is captured by the 
metadata in an information object. A data element such as a date has many different 
representations in today’s NAS, the FAA has already established an FAA Data Registry 
(FDR) that lists approved data standards in FAA-STD-060 format. Standardized data 
items have been listed with a preferred name, an identifier, data type (e.g., “string”), a 
definition, permissible values with value meanings, interchange format, maximum length, 
and unit of measure with minimum and maximum values where applicable. Each 
standard data element is listed with a steward organization, such as the FAA’s 
Aeronautical Information Division, ATA-100.” 

3.3 Data schemas 

FAA and Eurocontrol websites were searched for current and future methods for data 
handling in the US and European airspaces, respectively. Additional information was 
gathered from discussions with domain experts in the area of communication 
architectures and protocols currently competing for dominance in both the US and 
Europe. 

Currently, there is no global data standard for all aeronautical information. In Europe, 
Eurocontrol has created a data model called the Aeronautical Information Exchange 
Model (AIXM) intended for use throughout European airspace. The FAA does have 
initiatives with Eurocontrol (as well as with CAAs in the Americas) to help drive 
agreement on a global data model. See Ref. [6], 


On the FAA side (Ref. [14]): 
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“The FAA has invested in an Oracle-driven tool that is known as the FAA Data Registry 
(FDR). The FDR will hold metadata, or data about the operational data, that defines and 
describes those data elements to the format level. The FDR is built and will be managed 
to industry standards, the International Standards Organization (ISO)/International 
Electrotechnical Commission (IEC) Standard 11179, Specification and Standardization of 
Data Elements. Though the information and data flows in the NAS are extensive with 
significant interoperability concerns, there are identifiable data elements that constitute 
the core operational data that will be the initial focus of a standardization effort. 

Currently, the NAS interoperability issues present a substantial risk to modernization 
efforts. It is expected that standard data will greatly mitigate the technical and 
programmatic risks associated with acquiring new systems for the NAS.” 


3.4 Enterprise architecture frameworks 

Several websites were visited and documents read which describe the history and content 
of various architectural frameworks. The analysis looked at the theoretical beginnings of 
architectural framework schemes, such as the Zachman framework, but the main focus 
was on two more recent tailored manifestations of this paradigm, namely, the Department 
of Defense Architecture Framework (DODAF), formerly C4ISR, and the Federal 
Enterprise Architecture Framework (FEAF). 

These frameworks have resulted from federal government mandates for all of its agencies 
to use common process and products in the development of information architectures. A 
few documents were found which make comparisons between these frameworks, thus 
providing a basis for an assessment of the likelihood for architectures produced under 
these frameworks to be interoperable. 

Architecture frameworks will be an important influence in the future development of 
government agency infonnation technology acquisition and development strategies. In 
fact, the C4ISR architecture framework (and its successor, the DODAF) has been used in 
formulating information architectures within the military for almost a decade. 

We found little evidence of any similar work on the civilian side using FEAF. However, 
the legislation driving this transformation will affect both civilian and military 
organizations and how they share information. From the viewpoint of future 
interoperability between civilian and military infonnation architectures, it is prudent to 
understand what enterprise frameworks for architecture development are. 

It is important to understand that the subject of discussion in this section is architecture 
frameworks, not actual data architectures. These frameworks establish the common 
processes which all government agencies must use and products they must produce when 
designing information architectures. This makes it easier to track and quantify progress 
and to show compatibility with other systems designed under the same framework. 
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3.4.1 Introduction 

The growth in the size and complexity of federal government agencies, with the 
accompanying inefficiencies, cost overruns, performance lapses and lack of customer 
support has prompted public and congressional demand for more efficient and 
accountable practices. 

Two US government legislative acts in the 1990’s attempt to remedy this situation. One 
is the Information Technology Management Refonn Act (ITMRA), also called the 
Clinger-Cohen Act of 1996, which requires all government agencies to streamline IT 
acquisitions and emphasize life cycle management of IT as a capital investment. This 
legislation places emphasis on interoperable, integrated and cost-effective business 
practices and capabilities, particularly with respect to information technology (IT). 

The other is the Government Performance and Results Act (GPRA) of 1993, which 
requires all government agencies to set goals and measure performance against those 
goals, focus on results, service quality and customer satisfaction, and on improving tools 
to help achieve financial efficiency. 

A related document, Executive Guide: Improving Mission Performance Through 
Strategic Information Management and Technology (Other Written Prod., 05/01/94, 
GAO/AIMD-94-1 15), provides 1 1 guidelines or rules for achieving the goals of this 
legislation. Rule number 6 states: 

Focus on process improvement in the context of an architecture. 

The linkage is therefore made between the legislation and the concept of an “architectural 
framework”, which is intended to function as a common reference for developing, 
designing, implementing and assessing the performance of complex systems. Some of the 
goals are to improve coordination and communication within and between government 
agencies by encouraging the use of procedures and practices based on a common set of 
guidelines and rules. 

3.4.2 Genealogy of Architectural Frameworks 

In Figure 1 (from Ref. [17]), some of the main common architecture efforts of the past 20 
years are shown. The branch on the right, which includes C4ISR and DoDAF, refers 
primarily to DoD efforts. The branch on the left, starting with the Zachman framework 
and culminating in the TEAF is directed mainly at civilian government agencies. In this 
document, we ignore the TEAF in favor of the FEAF, since the TEAF is concerned 
specifically with the Treasury department, while the FEAF is more generic. 
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The diagram in Figure 1 seems to show that the DoD and civilian efforts have diverged. 
Fortunately, none of this work was performed in a vacuum, and ideas almost certainly 
flowed informally from one domain to the other. Also, both were probably influenced at 
some point in their development by the Zachman framework. The end result is a certain 
degree of commonality between DoDAF and FEAF. 

However, there are significant differences in level of maturity, level of detail, and 
primary focus. Brief descriptions of each are given in the following sections, together 
with discussions of similarities and differences. 

3.4.3 Zachman Framework 

In 1987, John Zachman published the Zachman Framework for Enterprise Architecture. 
See Ref. [18] for a description and further li nk s. He wrote "To keep the business from 
disintegrating, the concept of information systems architecture is becoming less of an 
option and more of a necessity." With this belief, he created the ZIFA . This organization 
is a network of information professionals who understand the value of EA for 
organizations participating in today's global economy. The mission of ZIFA is to promote 
the exchange of knowledge and experience in the use, implementation, and advancement 
of the Zachman Framework for Enterprise Architecture. This framework is used most 



frequently for business and industry information systems. 

The Zachman framework is influenced by principles of classical architecture that 
establish a common vocabulary and set of perspectives for describing complex enterprise 
systems. This influence is reflected in the set of rules that govern an ordered set of 
relationships that are balanced and orthogonal. By designing a system according to these 
rules, the architect can be assured of a design that is clean, easy to understand, balanced, 
and complete in itself. Zachman's Framework provides the blueprint, or architecture, for 
an organization's information infrastructure. 

The Zachman framework describes a holistic model of an enterprise's information 
infrastructure from six perspectives: planner, owner, designer, builder, subcontractor, and 
the working system. There is no guidance on sequence, process, or implementation of the 
framework. The focus is on ensuring that all aspects of an enterprise are well-organized 
and exhibit clear relationships that will ensure a complete system regardless of the order 
in which they are established. 

A version of the Zachman framework is shown in Figure 2. 


The meanings of the row labels are: 

Scope. Corresponds to an executive summary for a planner who wants an estimate of the 
size, cost, and functionality of the system. 

Enterprise model. Shows all the business entities and processes and how they interact. 
System model. Used by a systems analyst who must determine the data elements and 
software functions that represent the business model. 

Technology constrained model. Considers the constraints of tools, technology, and 
materials. 

Detailed representations. Represent individual, independent modules that can be 



Figure 2. The Zachman Framework 
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allocated to contractors for implementation. 

Note: Sometimes there is a sixth row, which shows the 
Working system. Depicts the operational system. 

The meanings of the column labels are: 

Data (What). Describes the entities involved in each perspective of the enterprise. 
Examples include business objects, system data, relational tables, or field definitions. 
Function (How). Shows the functions within each perspective. Examples include 
business processes, software application function, computer hardware function, and 
language control loop. 

Network (Where). Shows locations and interconnections within the enterprise. This 
includes major business geographical locations, separate sections within a logistics 
network, allocation of system nodes, or even memory addresses within the system. 
People (Who). Represents the people relationships within the enterprise. The design of 
the enterprise organization has to do with the allocation of work and the structure of 
authority and responsibility. The vertical dimension represents delegation of authority, 
and the horizontal represents the assignment of responsibility. 

Time (When). Represents time, or the event relationships that establish performance 
criteria and quantitative levels for enterprise resources. This is useful for designing the 
master schedule, the processing architecture, control architecture, and timing devices. 
Motivation (Why). Describes the motivations of the enterprise. This reveals the 
enterprise goals and objectives, business plan, knowledge architecture, and knowledge 
design. 


3.4.4 Comparison of architecture frameworks 

Some general conclusions were drawn from a thorough exploration of documents on the 
Internet concerning enterprise architecture frameworks: 

• The C4ISR (DoDAF) has a longer “history” of development and application to 
DOD services than the does the FEAF as utilized by civilian government agencies 

• The C4ISR (DoDAF) has more “maturity” and specific details concerning 
products and metrics to measure compliance 

• The FEAF data model(s) are admittedly still in the future according to 
Government Computer News as of June 2004. 

• The FEAF applications are still very business level oriented, with significant 
focus on inter-agency coordination and customer service. 

Figure 3 shows a comparison view from the Enterprise Architecture Special Interest 
Group in 2003 (Ref. [15]): 
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Differences in the Civilian vs. DoD Situations 


Civilian EA Situation 

FEAF available 1999 - no detailed 
product descriptions left guidance 
open 

FEAF guidance, not mandatory - 
Segments concept required 
volunteers 

Framework referenced EAP for 
process 

Each agency/user had to develop 
own concept of products and 
organization 

Many agencies used the FEAF, but 
no commonality of products or 
product presentation guaranteed 


DOD EA Situation 

C4ISR/DODAF Framework with 
product specifications available 1996 

Use of framework mandated by DoD 

Framework specific processes exist 

Contractors familiar with framework 
and products, use for system/ 
systems of systems architectures 

Many programs use the DODAF 


Figure 3 FEAF-DODAF Comparison from EA SIG 


The following comparison discussion is taken from Ref. [16]: 

“As shown by the color coding in Figure 4, the views and individual products of the 
C4ISR Architecture Framework, Version 2. 0 map to the cells of the Zachman Framework 
[Sowell, 1999]. (The figure maps only the most frequently-used DoD products, not all of 
them.) 

Blue cells indicate that the C4ISR Architecture Framework contains operational view 
products that map to the cells; orange cells indicate that the C4ISR Framework contains 
systems products that map to the cells; and blue/orange cells indicate that the C4ISR 
Framework contains both operational and systems products that map to the cells. (Note 
that there are no red cells; this reflects the fact that no technical view products map to the 
Zachman Framework. This is because the Zachman Framework does not call for the 
explicit modeling of the applicable rules and standards themselves, but assumes standards 
to apply within multiple cells.) 

Ovals have been overlaid onto the color-coded cells. These ovals represent individual 
products from the C4ISR Architecture Framework that correspond to the Zachman cell or 
cells onto which the oval is overlaid. Operational products are represented by blue ovals, 
and systems products by yellow or orange ovals. 
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Figure 4 Selected DOD Framework Products Mapped to Zachman Framework Cells 


Note that in some instances a cell is blue and orange, indicating that the C4ISR 
Architecture Framework contains both operational and systems products that correspond 
to the cell, but only a blue oval is shown in the cell. This is because not all the C4ISR 
Architecture Framework products are represented, only some of those that have been 
most frequently used in DoD architectures to date. The Function/Designer cell is blue 
and orange because the Operational Activity to Systems Function Matrix, while shown in 
the C4ISR Architecture Framework as a systems view product, is actually a pivot point 
between the operational and systems views. 

Through this product-to-cell mapping, the C4ISR Architecture Framework can provide 
templates and guidelines for modeling the enterprise features that correspond to the 
Zachman cells. 

Figure 5 illustrates the following correspondence between the FEAF components and the 
DoD Framework Views: the Business architecture roughly corresponds to the DoD’s 
Operational View, the Design architecture roughly corresponds to the DoD’s Systems 
View, and the FEAF’s Standards roughly correspond to DoD’s Technical View. (Data is 
distributed across the Operational and Systems Views in the DoD Framework.) 
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Figure 5 DOD Framework Views Mapped to Federal Framework Components 


As stated above, the FEAF guidance is built on the foundation of the Zachman 
Framework, with the Spewak Enterprise Architecture Planning overlaid onto the first two 
rows. Because, as shown earlier, the DoD Framework products can be used to fill out the 
cells of the Zachman Framework, the DoD products can also be used to fill out the cells 
of the FEAF. Figure 6 illustrates the mapping of selected DoD Framework products to 
the corresponding cells of the FEAF. Note that the FEAF has made some modifications 
and annotations to the Zachman Framework rows and column names. 
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Figure 6 Selected DOD Product Types Mapped to Federal Framework Zachman-based Cells 


Using the DoD Products in the FEAF: Federal Framework Pilot 
Architectures 

The Federal CIO Council seeks to develop, maintain, and facilitate the implementation of 
the top-level enterprise architecture for the Federal enterprise. This architecture will serve 
as a reference point to facilitate the efficient and effective coordination of common 
business processes, information flows, systems, and investments among Federal agencies. 

The approach taken to develop this Federal enterprise architecture is to develop 
architectures for selected high-priority cross-agency business lines, or “Federal 
Segments,” which will collectively constitute the enterprise architecture. 

With technical leadership provided by MITRE, a pilot effort is being conducted in which 
architecture descriptions will be constructed for one of the Federal Segments, to test the 
utility of the FEAF guidance. The candidate functional segment as of this writing is 
Grants. 

There was concern within the Federal Agencies Information Architectures Working 
Group (FAIAWG) that the Zachman Framework did not provide enough detailed 
direction to enable a useful architecture analysis. At this point, the FAIWG turned to the 
C4ISR Architecture Framework products for this additional architecture i nf ormation. 
Representatives of the FAIAWG worked with MITRE to examine the DoD products; 
they determined that the products were usable for the Federal Pilot with almost no 
modifications. Accordingly, four of the C4ISR Architecture Framework ' s essential 
products and one supporting product will be used to populate the appropriate cells of the 
modified Zachman Framework. 
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The pilot effort will produce, in accordance with the Federal Enterprise Architecture 
Framework (as amended by the DoD C4ISR Architecture Framework products), a 
narrow-scope architecture pilot segment that can be used to gather lessons-learned for 
further development or improvement of the Federal Enterprise Architecture Framework. 
This effort will also support the activities of the Federal CIO Council’s Emerging 
Information Technology and Interoperability Committee and contribute to the 
Committee’s near term vision, which is increased interoperability of Federal business 
processes to achieve a cost-effective, value-added contribution to the efficiency of the 
Federal enterprise. 

Figure 7 illustrates the products selected from DoD’s Framework that will be used as 
templates for populating the Federal Framework cells selected for the Pilot [Sowell, 
1999]. Although, as shown previously, many more DoD products map to the FEAF cells, 
only a few products were selected for a thin-thread example architecture for the Pilot. 
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Figure 7 DOD Framework Products Mapped to the Federal Pilot architecture Models 


Note that the Technical Architecture Profile does not actually map to the FEAF cells, 
because “Standards” are not explicit in the FEAF’s modified Zachman Framework. It is 
included here for completeness of the Pilot.” 
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4 Conclusions and Recommendations 


4.1 Data Flows in the NAS 

Based on the exercise of constructing the data table from APPENDIX A: Data Flows in 
the NAS Spreadsheet, here is a summary of areas that deserve attention: 

• Primary radar returns: An ROA may be sufficiently stealthy and/or physically 
small that its radar cross section (RCS) is insufficient to register on ATC primary 
radar. Primary radar is an important independent backup to secondary radar, 
which depends on the aircraft transponder signal. 

• Secondary radar returns: Will ROAs equip with transponders? Without them, 
some vital information (id, altitude) will not be available to the ATC controller. 

In addition, this would be the only way to see ROAs that are “invisible” to 
primary radar. Hence, ROAs that are sufficiently stealthy to be invisible to 
primary radar would require a transponder, or other means of detection. 

• Voice communications between the ROA pilot and the ATC controller: If voice 
li nk is via the ROA and a satellite, transmission latency may adversely affect 
controller workload. This is especially true in a busy airspace. The effect could 
be mitigated by a direct connection (say a telephone landline) between the AVCS 
and the ATC facility. But again, this introduces a novel procedure into the 
system, which could also cause additional delay. The direct ground connection 
might eliminate the “party-line” information used by pilots of manned aircraft in 
the vicinity of the ROA for situational awareness, depending on how the 
communication is implemented. 

• Command and control of ROA: Again, if the link involves a satellite hop, the 
combined latency of the ATC controller->ROA pilot communication and the 
ROA pilot->ROA communication may become an issue for timely execution of 
ATC controller clearances. 

• Display of real-time weather in the vicinity of the ROA: In an inhabited aircraft, 
the pilot can view adverse conditions on the cockpit weather display, if so 
equipped, or visually out the window, if there is sufficient visibility. This aids the 
pilot in avoiding dangerous weather conditions. The ROA pilot would be at a 
disadvantage in conditions of limited visibility, unless there is an appropriate 
onboard sensor (camera or radar?) and a weather display in the AVCS. 

• Terrain and obstacle avoidance: Current populated aircraft of a certain size 
and/or capacity must have a Ground Proximity Warning System (GPWS), or as it 
is now called, a Terrain Avoidance Warning System (TAWS). The ATC ground 
control also has a Minimum Safe Altitude Warning (MSAW) system, which 
alerts the controller, who then advises the pilot. If TAWS becomes a requirement 
for ROAs, control link latency could again become an issue. Similarly for the 
time for the ROA pilot to effect a timely response to an MSAW-generated 
advisory from the ATC controller. One possible solution would be to send 
MSAW data directly to the AVCS; note that this strategy creates a new data 
flow. 
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• Pilot report: Pilots of manned aircraft are often asked to report turbulence or 
other weather conditions at their assigned altitude for the benefit of other users of 
the airspace. If this ability is also desirable for ROAs, there needs to be some 
way of detecting the relevant conditions. For turbulence, this might be strain 
gauges for sensing structural stress, or cameras suitably placed so that they would 
provide the pilot with “shaky” images. 

• Navigation capabilities: As the NAS moves closer to “free flight” operational 
concepts, aircraft will need area navigation (RNAV) and appropriate Required 
Navigation Performance (RNP) capabilities. Will operators equip their ROAs in 
order to participate in these environments of the future? The tradeoff will be 
between the cost of equipage and the operational constraints imposed by non- 
compliance. 

• Collision avoidance: The FAA currently does not allow ROAs to use TCAS (or 
ACAS, the official ICAO terminology) in restricted airspace. Several questions 
thus come to mind. Will ACAS be part of a “sense-and-avoid” strategy for 
ROAs? If so, will ROAs be allowed to make cooperative collision avoidance 
maneuvers? How will the current restriction on TCAS usage for ROAs be lifted? 

• Equivalent level of safety (ELOS): The previous bulleted item is one part of the 
more comprehensive issue of achieving safety of flight for ROAs comparable to 
manned aircraft. This may involve new on-board and off-board systems, which 
implies new data flows. 

• Surface movement: Navigating around a busy airport’s runways, taxiways and 
aprons will be a real challenge for an ROA. One of the technologies being 
explored for enhancing ground controllers situational awareness, called Airport 
Surface Detection Equipment (System)-Model X, or ASDE-X, will rely on radars 
and multi-lateration of transponder signals from the vehicles on the ground, as 
well as in the air. Again, the question is, will ROAs equip with transponders so as 
to participate in this environment? Also, what info can be presented to the ROA 
pilot to support ground operations? 

4.2 NAS Modernization 

4.2.1 Administrator’s Flight Plan 

This is mainly an FAA mission statement, and is too high level to produce any observable 
implications for ROA impact on the NAS in terms of data modeling and sharing. 

4.2.2 NAS Architecture Version 5 

A very long list of operational improvements from the NAS Architecture Version 5 can 
found in Ref. [12]. Although a thorough analysis of all potential data issues was not 
made, a simple search of this list for “cockpit” revealed two on-board equipment items 
envisioned for the future air vehicle (presumably inhabited). They are listed below 
together with the operational improvements they would support. This would be a good 
area for follow-on work in the future. 
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Cockpit Display of Traffic Information Avionics 

o Flight Information Service-Broadcast (FIS-B), 
o Traffic Information Service-Broadcast (TIS-B), 
o Terminal Weather Information, 
o Hazardous Weather Information, 
o Shared Responsibility for Horizontal Separation, 
o Aircraft to Terrain Separation, 
o All-Weather Surface Operations, 
o Domestic RNP Navigation, 
o Oceanic Satellite Navigation, 
o Low- Visibility Operations, 

o Enhance Traffic Advisories Using Digital Traffic Data, 
Next-Generation Air/Ground Communications System Cockpit Display Unit 
o Current NAS Status Advisory 


4.2.3 OEP Version 6 

Listed below are specific elements taken from the OEP (Ref. [8]) that either mention new 
types of data or operational changes that may affect the way data is produced or 
distributed. The items serve only as a starting point for discussion. Their inclusion does 
not necessarily mean that there will be a direct effect on ROA operations. 

“Arrival/Departure Rate 4: Fill Gaps in Arrival and Departure Streams 
Controllers and Traffic Management Coordinators (TMC) will have improved 
information on arrival and departure demand and on available capacity. Decision support 
tools will assist them in developing improved sequencing. These plans will reflect an 
improved ability to project the future position of the aircraft, to optimize use of runways 
and fixes, and to account for separation requirements based on aircraft weight 
classification. The results will be an improved balancing of airport runway assets and an 
increase in airport throughput rate for both arrivals and departures. In addition, the 
execution of the plan will be improved through the provision of tools that show 
controllers the delay required for each aircraft. Arrival metering will transition from 
being mileage-based to being time-based. 

Arrival/Departure Rate 6: Coordinate for Efficient Surface Movement 

1. Situational awareness for ground controllers 

The establishment and distribution of real-time surface surveillance information will 
increase ground efficiency. Implementation of a seamless, real-time surface surveillance 
capability will reduce the range of uncertainty with regard to surface movement and 
resource demands. 

For air traffic controllers, positive identification and accurate real-time position 
information for aircraft and surface vehicles will result in better and timelier decision- 
making for surface operations. Controllers will need to request fewer position reports and 
will be able to monitor and quickly identify aircraft exiting runways after landing or 
departing aircraft at the runway, for example. Access to this information will allow for 
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greater efficiency in taxiing and departure and ramp queue management, since the taxi 
path clearance can be tailored and monitored automatically to achieve throughput 
objectives. Planning and proactive control of surface traffic is made possible when 
controllers know the position of aircraft before initial communication/contact is made. 

2. Queue information for tower and TRACON 

Surface surveillance with positive identification of targets also provides the basis for 
developing accurate and automatically updated aircraft timelines for use by local Traffic 
Management specialists to optimize the flow of traffic to and from the surface. The real 
time availability of airport and runway queue infonnation is also invaluable for 
operations in large TRACONS or where coordination of activities between multiple 
facilities is required. The generation of the information automatically ensures that it is 
timely and accurate. 

3. Event information for Collaborative Decision Making (CDM) 

For both Flight Operations Centers (FOCs) and Traffic Management Coordinators 
(TMCs), the availability of real-time surface surveillance information will support the 
development and implementation of applications designed expressly to improve traffic 
management and projections across all phases of flight. By adding information on both 
the individual flight movement and the aggregate flow on the surface, this knowledge can 
be incorporated more accurately into the operational planning and decision process, and 
done so more than 20 minutes sooner. The result is a vastly improved ability to project 
and identify periods of excess demand and other congestion. The more accurate, common 
situational awareness of the impacts across all phases of NAS operation will be directly 
reflected in more extensive CDM. 

4. Surface Management Systems (SMS) to improve surface management and integrate the airborne 
arrival/departure flow initiatives 

The availability of both surveillance and event information supports the development of 
SMS that can forecast queue, taxiway, and runway congestion. It will also provide 
alternatives for departure runway and taxi paths, as well as identify and offer queue 
ordering to meet departure and en route constraints that are part of other traffic flow 
initiatives. 

Airport Weather Conditions 1 : Maintain Runway Use in Reduced Visibility 
The goals are to continue arrival rates at higher level as weather deteriorates from VMC 
to IMC by increasing instrument approach services and to introduce performance-based 
navigation requirements for all weather operations. 

Airport Weather Conditions 2: Space Closer to Visual Standards 

Use cockpit tools and displays to achieve Visual Meteorological Condition (VMC) 

throughput capacity in all weather conditions. 

Airport Weather Conditions 3: Reconfigure Airports Efficiently 

Provide timely information about hazardous weather conditions and changes in wind 

conditions. 
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Airport Weather Conditions 4: Enhanced All-Weather Surface Operations 
Provide airport surface situational awareness in low visibility conditions. 

Enroute Congestion 3: Reduce Voice Communication 

Use Aeronautical Data Link System (ADLS) and Controller-Pilot Data Link 

Communications (CPDLC) to reduce dependence on voice communication.” 


4.2.4 Target System Description 

Many new systems and technologies are being proposed as part of TSD (Ref. [10]). The 
ones which have implications for new types of data and/or ways of producing, processing 
or transmitting that data include: 

• Plight Object Management System (POMS) 

• Aeronautical Information Management (AIM) 

• System Wide Information Management (SWIM) 

• Communication Management System (CMS) 

• Automatic Dependent Surveillance-Broadcast (ADS-B) 

• Traffic Information Service-Broadcast (TIS-B) 

• Plight Information Service-Broadcast (FIS-B) 

• Surveillance Data Network (SDN) (may be intended only for controllers, HS, 
other agencies on the ground) 

• General Weather Processor (GWP) 

Although SWIM is discussed in the next section, a good follow-on project would be to 
look more carefully at the other technologies listed above. 

4.2.5 SWIM 

The System Wide Information Management System concept is no less than a 
revolutionary transformation of the NAS information system. At this point it is still a 
concept, and many details of the architecture have not been developed. One of the 
primary elements of the proposal is the “publish-subscribe” paradigm, in which producers 
of data “publish” it on a network, and users of the data can “subscribe” to it by extracting 
suitably tailored versions of the data. Many issues associated with this paradigm will be 
have to be addressed, such as latency, integrity, and security. 

This area certainly bears watching, but it is difficult to make more detailed statements at 
this time about the interaction with ROAs. 

4.3 Data Schemas 

Given that this is an area under active development, with many uncertainties about future 
direction on both sides of the Atlantic, it is difficult to make definite statements about 
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data object compatibility and management at this time. Some more research and 
discussion with domain experts is needed. 

4.4 Enterprise Architecture Frameworks 

Although it seems obvious from the name, it is important enough to repeat that these are 
architecture frameworks, not actual data architectures. A framework only sets out the 
required processes and products of the architecture development. 

Given that no examples were found of data architectures developed under the FEAF, it is 
impossible to compare interoperability between FEAF-developed architectures and 
DODAF-developed architectures. 

However, it is also clear that there are strong similarities between the two frameworks, 
and if they are both applied rigorously, they should produce interoperable architectures. 
More future work could look at actual architectures produced by these frameworks, if and 
when the ones on the civilian side become available. 
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APPENDICES 

APPENDIX A: Data Flows in the NAS Spreadsheet 
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Data Category 


Data Description 


Remarks 


Weather 


Surveillance 


Aeronautical 


ATM Resource Management 


Information 
Attributes 

Data about atmospheric or Data 

meteorological conditions. 


Function 

Network 


Data about the actual locations of 
aircraft and any surface vehicles, 
building and other non- 
meteorological obstructions to 
aircraft. 


In some environments (e.g. 
oceanic/remote) this function may be 
partially achieved through 
knowledge of the vehicle's intent -- 
the flight plan. 


Transmission mode 


Navigational (or other) data People 

produced for pilots about the NAS 

airspace, NAS air traffic control 

system, and its assets. This 

includes airspace definitions, 

navigational communication aids 

and procedures, and changes 

thereto. This is long-term 

information which seldom 

changes. 

Data about the infrastructure Automated Systems 

assets of the NAS and their 
operational status or performance. 

Also, data used to negotiate, 
allocate or modify NAS airspace 
assets and associated airspace 
definitions. This refers to an up-to- 
the-minute status of NAS assets, 
such as a runway closure or a non- 
operating VOR. 



Operator Flight Recording 

Performance data monitored 
and/or recorded by operator or 
other non-ATC agencies to help 
improve reliability, safety, 
maintenance, and training. 

Time 

ATC Flight Recording 

Archived ETMS data for analysis. 
Flight data recorder (FDR) or 
cockpit voice recorder (CVR) data 
for incident investigation 

Motivation 

Strategic Flight Management 

Data associated with entering 
flight plans or profiles into the 
system for purposes of long-term 
flow control 

Remarks 

Tactical Flight Management 

Subsequent modification of flight 
plan for flow control purposes, for 
example, due to weather 
disturbances. 


Flight Control 

Data (or voice transmisions) 
associated with short-term flow 
control, separation management or 
conflict avoidance. For example, 
ATC-pilot conversations about 
clearances. 




Description 


Information that is transmitted and/or stored and 
must usually be processed to be useful. Includes 
voice and electronic or digital information. 

Airspace services or activities which use this 
data 

Nodes and direction of data flow from producer 
to user. May include automation systems as well 
as people. 


Indicates how the information is transmitted. The 
two major categories are voice and electronic 
data. Sub-categories of voice are HF, UFiF, and 
VFIF. For data, examples would be mode C, 
mode S, VDL mode 2, VDL mode 4, UAT. This 
gives an indication of what equipage is required 
for compatibility. 

Agents in the NAS that deal with this data, and 
perhaps make command and control decision 
based on the data and associated procedures. 


Computer-based equipment which processes 
data for purposes of display, decision aid, 
archiving, etc. An example would be radar data 
processors which turn raw primary and 
secondary radar returns into a useful display for 
the ATC controller. Another example would be 
the Center TRACON Automation System (CTAS) 
which aids in flow planning and sequencing of 
aircraft entering a TRACON. 



Can be a period of use, a latency requirement, a 
time horizon, or a perishibality period. A period of 
use might be "for the duration of the flight". A 
latency requirement bounds the time between 
the initiation of a transaction and its conclusion, 
for example, between a pilot clearance request 
and an ATC controlller response. A time horizon 
refers to the lead time needed for certain kinds of 
information, such as weather information to be 
used for flight planning. As an example of 
perishibility, let's say the ROA must pass a 
position report, and the position data in the 
reports is variable from Is - 600 s old, the data 
may be unsuitable for the intended purpose even 
if transfer times are very good (e.g. Is). 


Why is this data important to the user? Typical 
answers might be "for safe operation", "for 
operational efficiency", "for maintanence 
purposes". 

Further explains assumptions, reasoning or 
caveats. Might be a clarification question. 



Data 


Function 


Network (Flow) 


Transmission Mode 


Primary Radar return Situational awareness 

Independent surveillance 


Secondary Radar return* Situational awareness 

Cooperative surveillance 
Dependent altitude 
verification 


Pilot report* Situational awareness (for 

example, position, 
turbulence at altitude) 
Pilot-controller clearance Situational awareness 
conversation(s)* 

Controller observations Situational awareness 
(surface)* 

Multi-lateration sensor Airport surface situational 
data* awareness 


Radar -> Air vehicle -> Electromagnetic radiation 
Radar return processor -> 

Radar fusion processor -> 

Controller display 


Radar -> Air vehicle -> Transponder signals: 1 030 
Transponder -> Radar MHz interrogate and 1090 
return processor -> Radar MHz reply 
fusion processing - 
>Controller display 


Pilot -> Controller -> Other VHF, UHF or HF 
pilots depending on location. 

Pilot(s) <--> Controller(s) 


Controller eye -> Brain 


Transponder, radar Radar pulses, transponder 

transmissions -> Radar signals 

receivers -> Controller 
display 



ACAS traffic alert 


Situational awareness 


Aircraft -> Aircraft (Pilot) Transponder signals 


ACAS resolution 
advisory 

ADS-B message packet 

TIS-B message packet 
TAWS Data 


Situational awareness Aircraft -> Aircraft (Pilot) Transponder signal 
Conflict resolution and 
collision avoidance 


Situational awareness Aircraft -> Aircraft or Competing modes: 

Cooperative surveillance Aircraft -> Ground control Universal Access Transmit 

(UAT), Mode S, orVDL 
Mode 4 (Europe only) 


Situational awareness Ground control -> Aircraft 
Cooperative surveillance 

Situational awareness Terrain database, Flight Electronic signals 

(pilot) computer -> Pilot 

Avoidance of controlled 
flight into terrain (CFIT) 



M SAW/E M SAW Data* 


RAAS Data 
ASDE-X Data 


Situational awareness Terrain database, 

(controller) trajectory computer -> 

Avoidance of controlled controller display 

flight into terrain (CFIT) 


Avoidance of controlled 
flight into terrain (CFIT) 


Electronic signals 



People 

Automated Systems 

Time 

Controllers 

Computers that process 
data, correlate tracks, 
perform monioring and 
detection tasks 

2-8 sec update rate 

Controllers, pilots (who 
can turn off the 
transponder) 

Computers that process 
data, correlate tracks, 
perform monioring and 
detection tasks 

2-8 sec update rate 

Pilots, controllers 


Seconds to minutes 

Pilots, controllers 


Seconds to minutes 

Controllers 


Immediate 

Controllers 

Computer systems that 
process and display raw 
radar and transponder 
returns 

2-8 sec update rate (?) 


Motivation 


Monitoring for safety and 
conformance to flight plan 
(air vehicle) 


Monitoring for safety and 
conformance to fligh plan 
(air vehicle) 


Safety, comfort (air 
vehicle) 

Safety (air vehicle) 


Monitoring for safety and 
efficiency in surface 
movements 

Monitoring for safety and 
efficiency in surface 
movements 



Pilots 


ACAS data processing 


Seconds to minutes 


Pilots 

Pilots, controllers 

Pilots, controllers 
Pilots 


Safety (air vehicle) -- alerts 
pilot(s) to potential conflict 
several seconds in 
advance 


ACAS data processing Approx 35 seconds before Safety (air vehicle) -- 

closest point of approach provides pilot(s) with 
(CPA). See table to right instructions for evasive 
for details about advisory maneuver 
time to CPA thresholds. 


Milliseconds to seconds Safety (air vehicle) 


Radar, transponder data Milliseconds to seconds Safety (air vehicle) 

processors and data fusion 

systems 

Computers that match Seconds Safety 

aircraft position with 
ground and/or ground 
obstacles 



Controllers 


Seconds 


Safety 


Computers that match 
aircraft position with 
ground and/or ground 
obstacles 



Remarks 


1 . This category does not have star because an ROA may 
have a very small RCS that is difficult to detect with primary 
radar (some ROA's are purposely stealthy, for example). 

2. Update rates vary according to airspace (generally 8s in 
en-route and 2-4s lower down). Here is a case where 
latency is not the right term. The latency is actually very 
short; the update rate comes from the sweep time for the 
radar head, or from the fusion processing. 

1 . The "*" for this category depends of course on the ROA 
being equipped with a transponder. 

2. Update rates vary according to airspace (generally 8s in 
en-route and 2-4s lower down). Here is a case where 
latency is not the right term. The latency is actually very 
short; the update rate comes from the sweep time for the 
radar head, or from the fusion processing. 

An ROA pilot can report turbulence only if there are on- 
board sensors (strain gauges, cameras) that can detect it. 

Pilots listen in on "party line" for information on nearby 
aircraft 


1 . There are some general issues here, for example, when 
to activate/deactivate transponders, 

2. There are equipage issues for ROAs, so as to be visible 
to surface multi-lateration systems. 

3. The sensor here is either secondary radar or ADS-B or 
both 



1 . No "*" here because it is not clear that ROAs will equip 
with TCAS. The FAA does not even allow TCAS to be used 
by ROAs in controlled airspace. 

2. Airborne Collision Avoidance System (ACAS) is the 
International Civil Aviation Authority (ICAO) terminology that 
includes TCAS. There are three types of ACAS; all of them 
are electronic systems put on board aircraft to help reduce 
the risk of mid-air collisions: ACAS I, ACAS II and ACAS III. 
Version 7.0 of TCAS II (Traffic Alert and Collision Avoidance 
System) is currently the only implementation that meets the 
worldwide ACAS II standards set by ICAO . TCAS II is 
produced by two manufacturers: Rockwell Collins and 
Honeywell. 

3. TCAS will display different traffic symbols on the TCAS 
traffic displays. The type of symbol selected by TCAS is 
based on the intruder’s location and closing rate. The 
symbols change shape and color to represent increasing 
levels of urgency. An open diamond is a surveillance target 
beyond PA (Proximity Advisory) range. A PA symbol is a 
filled diamond that represents an intruder that is +/- 1 ,200 ft. 

1 . No "*" here because it is not clear that ROAs will equip 
with TCAS. The FAA does not even allow TCAS to be used 
by ROAs in controlled airspace. 

2. Although both TCAS I and II will provide traffic alerts 
(TA's), only TCAS II (or ACAS) will deliver a resolution 
advisory (RA). TCAS II bases the alarms on a five second 
crew reaction time to achieve adequate separation. 

Note: This technology is not in wide use yet. It has been 
studied in Alaska during the Capstone program, is used by 
some cargo carriers (UPS, for example), and there is a 
ground support network being tested on the East Coast. All 
current major airliners (Boeing and Airbus) come equipped 
with ADS-B transmit capability). The WP 3 team will come 
back to this in more detail in the FY'05 phase of our study 
when we look at future operations. 

TIS-B includes data from all types of surveillance except 
pireps. It can be useful to equipped aircraft that are outside 
of traditional coverage. 

Will ROAs equip with this capability? Will the database be 
on the ground or in the aircraft? 

Terrain Awareness and Warning System (TAWS) is the new 
internationally accepted term for what was formerly known 
as Enhanced Ground Proximity Warning System or 
EGPWS, which has a terrain look-ahead capability. GPWS 
is a term used to apply to the first generation of TAWS 
equipment, which could only look straight down. 



1. Normally this data goes to controllers, who must then 
warn pilots. In the case of ROAs, the control loop could be 
shortened considerably if this went straight to the ROA 
ground control station. THis would be a NEW data flow. 

2. Minimum Safe Altitude Warning (MSAW) utilizes 
secondary surveillance radar (SSR) repsonses from aircraft 
transponders and trajectory tracking to determine whether 

it is likely that the aircraft may be exposed to an 
unacceptable risk of controlled flight into terrain (CFIT). 
MSAW is normally implemented locally within the radar 
display system software and compares predicted aircraft 
trajectories with a database of levels at which an alert will 
be triggered within specific geographic areas. The system 
is technically complex (due to need to compensate for 
radar processsing delays) and requires careful installation, 
commissioning and operation to ensure that false alert 
occurrences do not present a hazard to operations. 



Europe vs. US 


Europe may be ahead of US in fusion system 
development (ARTAS). 


Europe may be ahead of US in fusion system 
development (ARTAS). 


Both Europe and the US are pushing deployment of multi- 
lateration systems on the surface. ASDE-X in the US is 
currently in trials. 



Own 

Threshol 

Threshol 

Threshol 

Threshol 


d 

d 

d 

d 






Seconds Seconds lateral 


Inhibited 



45 


45 


45 


25 


30 


30 


30 


0.1 


0.3 


RA 

NM 

lateral 


inhibited 


0.066 


0.066 


0.082 


0.105 


0.122 




Threshol 

Threshol 

d 

d 


Altitude 


Altitude 




TA 

RA 

Feet 

Feet 

1200 

Inhibited 

1200 

300 

1200 

300 

1200 

300 

1200 

300 

1200 

300 



Data 

Function 

Network (Flow) Transmission Mode 

People 

Standard Briefing* 

Go/No go decision and 
flight planning 

FSS orNOAAWSO -> 
Pilot/FOC 

Pilot, weather forecasters 
and briefers 

Abbreviated Briefing* 

Go/No go decision and 
flight planning with 
selected data 

FSS orNOAAWSO -> 
Pilot/FOC 

Pilot, weather forecasters 
and briefers 

Outlook Briefing* 

Long range flight planning 
(> 6 hours ahead) 

FSS orNOAAWSO -> 
Pilot/FOC 

Pilot, weather forecasters 
and briefers 

Terminal Forecast* 

Airport condition advisory 

ASOS, ATIS, AWOS, 
selected navigation aids -> 
Pilot/FOC 

Pilot 



Automated Systems Time 

Minutes to hours before 
departure 

Motivation 

Safety (air vehicle) 

Remarks 

Each row from 5 down 
is a component of one 
or more of 1-4. 

Minutes to hours before 
departure 

Safety (air vehicle) 


Minutes to hours before 
departure 

Safety (air vehicle) 


Issued 3 times a day, good 
for 24 hours 

Safety (air vehicle) 

Last 6 hours of 24-hr 
forecast includes 
expected conditions: 
VFR, MVFR, IFR, 
LIFR (sic) 

Note that ATIS does 
not give a forecast — 
it's an actual, like 
METAR 



Data 

Function 

Network (Flow) 

Transmission Mode 

People 

Automated Systems 

Flight object (flight 
profile, plan)* 

Planning (commercial 
strategic) 

AOC <--> Service provider 

Electronic, telephone, in 
person 

Flow planners, AOC 

Operator computer, HOST 
computer 

Flight object (flight 
profile, plan)* 

Planning (military strategic) Base Ops <--> Service 
provider 

Electronic, telephone, in 
person 

Flow planners, Base Ops 

Military computer, HOST 
computer 

Flight object (flight 
profile, plan)* 

Planning (space launch 
strategic) 

Service provider <--> 
Space launch company (?) 

Electronic, telephone, in 
person 

Flow Planners, Mission 
planners 

Launch provider computer, 
HOST computer 



Time 


Motivation 


Remarks 


Pre-departure planning up Efficiency (service Flight object could be generated well in 

to push-back clearance provider); advance and populated as flight time 

request Meet demand (airline) approaches. 

Pre-departure planning up Efficiency (service Flight object could be generated well in 

to initial clearance request provider); advance and populated as flight time 

Accomplish mission goals approaches. 

(military) 

Pre-launch planning up to Minimize impact to system Flight object could be generated well in 

launch initiation (service provider); advance and populated as flight time 

Accomplish mission goals approaches. 

(space launch company) 



Data 


Flight object (flight 
profile, plan)* 
(commercial tactical) 
Flight object (flight 
profile, plan)* 

(military tactical) 

Flight object (flight 
profile, plan)* 

(space launch tactical) 
Flight object (flight 
profile, plan) 

(ROA tactical) 

Aircraft characteristics* 


Function 

Network (Flow) 

Planning 

Service provider <--> 
Aircraft (sometimes AOC is 
in the loop) 

Planning 

Service provider <--> 
Aircraft 

Planning 

Service provider <--> 
Launch controller 

Planning 

Service provider <--> ROA 
ground control 


Tactical control and Computer database -> 

monitoring of aircraft ATC controller 


Transmission Mode 


Electronic database 
retrieval. 



People 

Controllers, Pilots, AOC 
Controllers, Pilots 
Controllers, Launch control 
Controllers, ROA pilot 

ATC controller 


Automated Systems 


Time 


Push-back clearance 
request to end of flight 

Initial clearance request to 
mission review 

Launch to outer space (?) 


Initial clearance request to 
mission review 


Motivation 


Efficiency and safety 
(service provider and 
airline) 

Safety (service provider 
and military) 

Safety (service provider 
and space launch 
company) 

Safety (service provider 
and the ROA company (?)) 


Safety, efficiency 


Flight Data Processors Seconds to minutes ? 

folks. These systems 

support the controllers, 

and use it to predict the 

a/c's progress through the 

airspace. This, in turn, is 

used to allocate ATC/M 

resources, plan 

sequences, deconflict 

traffic, etc. This information 

is of varying level of 

granularity and accuracy 

(from very poor to 

reasonable - never as 

good as the aircraft itself), 

depending on the ATC or 

ATM facility involved (and 

ATC vs. ATM is an 

important distinction here). 



Remarks 


Based on FCFS 


Based on FCFS except for 
national defense, e.g. 

Space launch has priority 


Goal is to "file and fly". 


That information the ATC 
controller needs to 
determine what he/she can 
ask of the vehicle. Based 
on conversations with 
former FAA personnel 
currently working for 
Boeing, this information 
(as stored in the ATC 
computers) is limited to 
aircraft type, whether it is a 
prop or a jet, and what its 
climb and descent rates 
are. 

However, based on these 
same conversations, it 
appears there are other 
informal sources of 
information, such as 
scanned-in performance 
data, folklore ("the C-17 
behaves like a 757"), and 
access to the Internet. But 
there is no uniform 
standard or requirement 
for detailed performance 
information. The flight plan 
has only very basic 
information. 

1 . Automation systems 
may need some of this 
information, but more 
detailed, say, as a function 



Data 

Function 

Network (Flow) 

Transmission Mode 

Pilot-Controller 

Control (commercial 

Service provider <--> 


Clearance 

Conversations* 

tactical) 

Aircraft (sometimes AOC is 
in the loop) 


Pilot-Controller 

Clearance 

Conversations* 

Control (military tactical) 

Service provider <--> 
Aircraft 


Pilot-Controller 

Clearance 

Conversations* 

Control (ROA tactical) 

Service provider <--> ROA 
ground control 


Command and control 

Conformance to flight plan, Pilot -> Air vehicle control 

Tactile, physical, 

inputs* 

(manned aircraft) 

vehicle control and 
management 

system 

electronic. 

Command and control 

Conformance to flight plan, 

Pilot -> Air vehicle control 

Line of sight (LOS) or 

inputs 

(ROA) 

vehicle control and 
management 

system 

SATCOM link. 

Vehicle Sensor Data* 
(manned aircraft) 

Situational awareness. 
Vehicle control and 
management (part of 
control loop). 

Air vehicle sensors -> Pilot 

Electronic. 


Vehicle Sensor Data 

Situational awareness. 

Air vehicle sensors -> Pilot Line of sight (LOS) or 

(ROA) 

Vehicle control and 

SATCOM link. 


management (part of 



control loop) 




People 


Automated Systems Time 


Motivation 


Controllers, Pilots, AOC 
Controllers, Pilots 
Controllers, ROA pilot 

Pilot 


Push-back clearance 
request to end of flight 

Initial clearance request 
mission review 

Initial clearance request 
mission review 


Milliseconds 


Pilot 


Flight control computers Milliseconds to several 

seconds 


Pilot 


Sensors, flight control Milliseconds to Seconds 
computers 


Pilot 


Sensors, flight control Milliseconds to Seconds 
computers 


Efficiency and safety 
(service provider and 
airline) 

Safety (service provider 
and military) 

Safety (service provider 
and the ROA company (?)) 


Safety and efficiency 


Safety and efficiency 


Safety, efficiency 


Safety, efficiency 



Remarks 


Based on FCFS 

Based on FCFS except for 
national defense, e.g. 

Goal is to "file and fly". 


The new element for an 
ROA is the (exterior) 
transmission link from the 
pilot to the air vehicle, 
which may give rise to 
unacceptable control loop 
delay. 


The new element for an 
ROA is the (exterior) 
transmission link from the 
air vehicle to the pilot, 
which may give rise to 
unacceptable control loop 
delay. 

Important issues will be 

1. Standardization of 
ground control station, 

2. Inclusion of certain 
"cockpit-like displays", 



Data 


Function 


Network (Flow) 


Transmission Mode 


Notices to Airmen* 


Aeronautical Information 
Plan* 


1 . 

Airspace Definitions* 
la. 

Rules of the air* 


1b. 

Communications 


1c. 

Approach Routes 


System used to provide Service provider>pilots 
updates on the status of 
the NAS 

Each nation is required to Regulator -> Users 

maintain all aeronautical 

information concerning 

their ATM system that is 

pertinent to those using it, 

e.g., communication links, 

airspace, instrument 

approach plates, etc.. 


Define classes of airspace 
and equipment 
requirements 
Procedures developed by 
international/national 
regulatory bodies that 
establish operational 
procedures 

Systems that provide links 
between operators and 
service providers for the 
transfer of information. 


ICAO -> CAAs -> Service 
providers and operators 

ICAO -> CAAs -> Service 
providers and operators 


ICAO -> CAAs -> Service 
providers and operators 


Land line telephone, 
SATCOM 


Approach and landing ICAO -> CAAs -> Service 

providers and operators 



l d. 

Navigation Aid Data* 

le. 

Emergency Procedures* 
Letters of Agreement 


Route navigation ICAO -> CAAs -> Service 

providers and operators 

Emergency response ICAO -> CAAs -> Service 

providers and operators 

Contracts between centers Center <--> Center 
that specify the specifics of 
handoff procedures, for 
example. 


Official documents. 



People 


Automated Systems Time 


Motivation 


Service providers, pilots 


Pilots, regulators 


Airspace planners, service 
providers, air vehicle 
operators 

Airspace planners, service 
providers, air vehicle 
operators 


Pilots, controllers 


Minutes to days prior to 
use of information. May 
stay current for months. 

Electronic database (?) Days to multi-years. 


HOST computer database 

(?) 

HOST computer database 

(?) 


HOST computer database 2 sec (?) 

(?) 


ICAO requires every 
member nation to provide 
this information, keep it 
updated, according to a 
global plan. 


HOST computer database 

(?) 



HOST computer database 

(?) 

HOST computer database 

(?) 

Variable. Can exist several Efficiency and safety 
months to years without 
change, or may be 
modified quickly to fix a 
minor problem. 


Flow planners, regulators, HOST computer database 
controllers, operators (?) 



Remarks 


(1) Each ICAO region 
(9 of them) has their 
own individual 
implementation of the 
global plan. 

(2) The current trend in 
ATC is to separate 
functions of regulation 
and provision of 
service. FAA is one of 
few organizations in 
world which still does 
both. 

(3) Operators may be 
involved in developing 
the plans. 

(4) Many changes 
occur irregularly based 
on circumstances and 
arrival of new 
information. Charting 
cycle is 56 days, for 
example. 

Part of AIP. 


Part of AIP. 


Part of AIP. 

There could be a 
latency issue for ROAs, 
if these operator-ATC 
comm links are used for 
critical data exchange. 


May be an issue for 
ROAs if RNAV/RNPxx 
routes are used and 
ROAs are not 
RNAV/RNPxx capable. 



Operators are not 
always advised of these 
agreements. This can 
be a problem for flight 
planning. 



Data 

Function 

Network (Flow) 

Transmission 

Mode 

People 

FOQA Data 

Recording and 
analysis of critical 
flight data in the 
operation of aircraft 

Aircraft --> 
Recorder --> 
Analysts, Training 
pilot, computer 
database (for 
reports) 


Analysts, Training 
pilot, computer 
database 

Aircraft status: 

On-board 

information* 

Health 

management, cost 
containment, 
efficient 
maintenance 

Vehicle sensor(s) -> 
Pilot/Operator 

Electronic data link. 

Pilot, operators, 
engineers, 
maintenance, 
engineering, 
training, record- 
keeping in FAA 
(certification) 



Automated 

Systems 


Time 


Motivation 


Remarks 


From engine start to Flight safety, quality New ROA element: Recommend using 



shutdown for 
collection. Various 
periods of time for 
analysis and 
training. 

of training, 
adherence to 
procedures, 

data must be 
sensed in ROA 
control center 
(inputs on ground 
rather than aboard 
aircraft) as well as 
ROA. 

AVCS (air vehicle 
control station) for ROA 
controller 

Sensors and 
operator computer 
databses 

Vehicle startup to 
shutdown 

Safety, efficient 
resource utilization, 
achieve mission 
goals 

Aircraft systems 
and performance 
data. This data goes 
to AOC, rather than 



ATC. 

Engine condition 
monitoring, which is 
automated and 
transmitted on 
some Boeing 
Commercial 
models, is used by 
the operator to 
support on- 
condition 
maintenance and 
replacement. It has 
been a successful 
strategy in that it 
has reduced the 
numbers of in-flight 
shut-downs and 
speeds 
unscheduled 
maintenance by 
having parts ready 
for an aircraft when 
it arrives at its 
destination. 



Data 


Function 


Network (Flow) 


Transmission Mode 


ETMS Data (archival)* 


Flight Data Recorder 
(FDR) Data 

Cockpit Voice Recorder 
(CVR) Data 


Analyze traffic flows in the Volpe Center --> Analysts 
NAS. 

Accident investigation Vehicle sensors -> 

Recorder -> Investigator 
computers 

Accident investigation Pilots -> Recorder -> 

Investigator tapes 


Electronic 


Electronic 


Electronic 



People 

Automated Systems 

Time 

Motivation 

Service Provider, Analysts 

Days to hours 

Capacity, efficiency 

Validation of tools and 
models for traffic flow 
analysis and simulation 

NTSB 

Sensors, recorder 

Record for last 30 minutes 
(by continually writing over 
tape) 

Safety 

NTSB 

Sensors, recorder 

Record for last 30 minutes 
(by continually writing over 
tape) 

Safety 



Remarks 



Data 


Function 


Network (Flow) 


Transmission Mode 


NOTAMS* 

ETMS Data (real time: 
traffic surges, gaps, 
volumes)* 


ETMS Data (archive)* 


SAMS/MAMS* Data 


Announce temporary 
changes to the NAS 

Manage traffic flow in the 
NAS. 


Sofware tools used to 
schedule SUA. 


Service provider -> 
Operators & ATC 
controllers 

ATCSCC -> Facility Traffic 
Managers / Controllers -> 
Operators / Pilots 


SUA manager <--> Traffic 
Manager -> Operators/ 
pilots 


Non-real-time scheduling ATCSCC -> Stakeholders 
and flow analysis 



Agents 

Time 

Motivation 

Remarks 

Service Provider, 
Operators/Pilots, ATC 
controllers 

Days to hours 

Safety 


Service Provider, 
operators/pilots 

Days to hours 

Capacity, efficiency 

(1) Enhanced Traffic 
Management System. 

(2) Canada, Mexico, 
Europeans have similar 
systems, and 
information can be 
shared with U.S. 

Service Provider, 
Stakeholders 

Days years 

Capacity, efficiency 

Can be used to help 
improve airspace 
structure, scheduling 
algorithms, etc. 

SUA Manager, Traffic 
Manager, operators, pilots 

Hours to minutes 

Safety and efficiency 

Special use airspace 
tools (military and FAA). 
See FAA Order 7450.1 . 



APPENDIX B: Current NAS Sensors and Systems and 
Data Attributes 

From Ref [4], 


Table B- 1: Surveillance Sensors/Systems 


Automation/ 
Processing 
System (SINK) 

Sensors feeding into 
System (SOURCE) 

Traffic Model 

Traffic type 

Data Attributes 

ARTS 

ASR-7,8,9; ASR-11; 
ATCBI; MODE-S 

Surv-1 

Surv: 128 bits 

Surv: Custom Model 
Peak Loadinq: peak rate = 
544 msgs/sec & avg rate = 
70 msgs/sec 

Busy Loadinq: peak rate = 
544 msgs/sec & avg. rate = 
35 msgs/sec 

STARS 

ASR-7,8,9; ASR-11; 
ATCBI; MODE-S 

Surv-1; Surv-3 

Product Error Msg.: 
112 bits 

Runway Config.: 192 
bits 

Uniform (constant) 

Product Error Msg.: 1 
msg./min 

Runway Config.: 5 msgs/hr 

HCS (w/PAMRI) 

ASR-7,8,9; ASR-11; 
ATCBI; MODE-S 

Surv-1; Surv-3 

Product Error Msg.: 
112 bits 

Runway Config.: 192 
bits 

Uniform (constant) 

Product Error Msg.: 1 
msg./min 

Runway Config.: 5 msgs/hr 

DARC 

ASR-7,8,9; ASR-11; 
ATCBI; MODE-S 

Surv-1; Surv-3 

Product Error Msg.: 
112 bits 

Runway Config.: 192 
bits 

Uniform (constant) 

Product Error Msg.: 1 
msg./min 

Runway Config.: 5 msgs/hr 

AMASS 

ASDE-3; ASR-7,8,9; 
ASR-11; 

Surv-1 

Surv: 128 bits 

Surv: Custom Model 
Peak Loadinq: peak rate = 
544 msgs/sec & avg rate = 
70 msgs/sec 

Busy Loadinq: peak rate = 
544 msgs/sec & avg. rate = 
35 msgs/sec 

DBRITE TDU 

DBRITE 

Surv-7 (Aut-4) 

DBRITE Display 
(data message): 704 
bits 

VCU Data: 480 bits 

DBRITE Display: Uniform 
(constant) 

VCU Data: Negative 
Binomial 

DBRITE Display (data 
message): 10/sec 
VCU Data: 

Peak: 2413 msgs/sec 
Avq: 1073 msgs/sec 

STARS TDW 

STARS 

Surv-7 (Aut-4) 

DBRITE Display 
(data message): 704 
bits 

VCU Data: 480 bits 

DBRITE Display: Uniform 
(constant) 

VCU Data: Negative 
Binomial 

DBRITE Display (data 
message): 10/sec 
VCU Data: 

Peak: 2413 msgs/sec 
Avq: 1073 msgs/sec 

ASR-7,8,9 

HCS, STARS, ARTS 

Surv-9 (Surv- 
3) 

Product Error Msg.: 
112 bits 

Uniform (constant) 
Product Error Msg.: 1 
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Runway Config.: 192 
bits 

msg./min 

Runway Config.: 5 msgs/hr 

ASR-11 

HCS, STARS, ARTS 

Surv-9 (Surv- 
3) 

Product Error Msg.: 
112 bits 

Runway Config.: 192 
bits 

Uniform (constant) 

Product Error Msg.: 1 
msg./min 

Runway Config.: 5 msgs/hr 

ARSR 

HCS, STARS, ARTS 

Surv-9 (Surv- 
3) 

Product Error Msg.: 
112 bits 

Runway Config.: 192 
bits 

Uniform (constant) 

Product Error Msg.: 1 
msg./min 

Runway Config.: 5 msgs/hr 


Table B- 2: Weather Sensors/Systems 


Automation/ 
Processing 
System (SINK) 

Sensors feeding into 
System (SOURCE) 

Traffic Model 

Traffic Type 

Data Attributes 

N EXRAD 
Principal User 
processor 

NWXRAD WSR- 88D 

Wx-2 

Lightening 
Detection Data: 
152 bits 

Uniform (constant) 
Lightening Detection 
Data: 1/min 

N EXRAD WSR- 
88D 

WARP Processor at ARTCC 

Wx-2 

Lightening 
Detection Data: 
152 bits 

Uniform (constant) 
Lightening Detection 
Data: 1/min 

DSR 

WARP Processor at ARTCC 

Wx-10 

Weather: 64 bits 

Weather: Negative 

Binomial 

Weather: 

Peak: 75 msqs/sec 
Busy (avq.): 15 msgs/sec 

URET CCLD 

WARP Processor at ARTCC 

Wx-10 

Weather: 64 bits 

Weather: Negative 

Binomial 

Weather: 

Peak: 75 msqs/sec 
Busv (avq.): 15 msgs/sec 

CTAS /TMA 

WARP Processor at ARTCC 

Wx-10 

Weather: 64 bits 

Weather: Negative 

Binomial 

Weather: 

Peak: 75 msqs/sec 
Busv (avq.): 15 msgs/sec 

CTAS WS 

WJHTC ( to be replaced by 
WARP) 

Wx-10 

Weather: 64 bits 

Weather: Negative 

Binomial 

Weather: 

Peak: 75 msqs/sec 
Busv (avq.): 15 msgs/sec 

AIS remote 

AIS WS 

Wx-10 

Weather: 64 bits 

Weather: Negative 

Binomial 

Weather: 

Peak: 75 msqs/sec 
Busv (avq.): 15 msgs/sec 

AIS WS 

AIS remote 

Wx-10 

Weather: 64 bits 

Weather: Negative 

Binomial 

Weather: 

Peak: 75 msqs/sec 
Busv (avq.): 15 msgs/sec 

ASOS 

ADAS 

Wx-10 

Weather: 64 bits 

Weather: Negative 

Binomial 

Weather: 

Peak: 75 msqs/sec 
Busv (avq.): 15 msgs/sec 

US Customs 

WARP Processor at ARTCC 

Wx-10 

Weather: 64 bits 

Weather: Negative 

Binomial 

Weather: 
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Automation/ 
Processing 
System (SINK) 

Sensors feeding into 
System (SOURCE) 

Traffic Model 

Traffic Type 

Data Attributes 





Peak: 75 msqs/sec 
Busy (avq.): 15 msgs/sec 

HOST 

ARINC/AFTN; AWP; ARSR; 
ASR-7,8,9; ASR-11 

Wx-2 

Lightening 
Detection Data: 
152 bits 

Uniform (constant) 
Lightening Detection 
Data: 1/min 

STARS/ARTS 

ARSR; ASR-7,8,9; ASR-11 

Wx-2 

Lightening 
Detection Data: 
152 bits 

Uniform (constant) 
Lightening Detection 
Data: 1/min 

WMSCR 

ARINC/AFTN; ADAS; AFSS 
FSDPS; 

Wx-1 , Wx-2 



ETMS WS & SD 

ETMCC (Volpe) 

Wx-10 

Weather: 64 bits 

Weather: Negative 

Binomial 

Weather: 

Peak: 75 msqs/sec 
Busy (avq.): 15 msgs/sec 

DOTS+ 

Kovouras; ETMCC (Volpe) 

Wx-2 

Lightening 
Detection Data: 
152 bits 

Uniform (constant) 
Lightening Detection 
Data: 1/min 

AFTN/FIRs 


Wx-10 

Weather: 64 bits 

Weather: Negative 

Binomial 

Weather: 

Peak: 75 msqs/sec 
Busy (avq.): 15 msgs/sec 

SI R/ODAPS 


Wx-2, Wx-10 



ODAPS 

WMSCR 

Wx-2, Wx-10 



ITWS 


Wx-1, Wx-10 



WARP 

FAABWTG (at 
ATCSCC) 


Wx-10 

Weather: 64 bits 

Weather: Negative 

Binomial 

Weather: 

Peak: 75 msqs/sec 
Busy (avq.): 15 msgs/sec 

WARP Processor 
(at ARTCC) 


Wx-1, Wx-10 



ADAS 


Wx-1 

Current surface wx 
obs: 1600 bits 
Hourly surface wx 
obs: 1600 bits 
Special surface wx 
obs: 1600 

Uniform (constant) 
Current surface wx obs: 
1/min 

Hourly surface wx obs: 
137/hr 

Special surface wx obs: 
10/hr 

ARINC/SITA ODL 
Server 


Wx-10 

Weather: 64 bits 

Weather: Negative 

Binomial 

Weather: 

Peak: 75 msqs/sec 
Busy (avq.): 15 msgs/sec 

ARINC Data 
Network 


Wx-10 

Weather: 64 bits 

Weather: Negative 

Binomial 

Weather: 

Peak: 75 msqs/sec 
Busv (avq.): 15 msgs/sec 

ATCT GSD 


Wx-2 

Lightening 
Detection Data: 
152 bits 

Uniform (constant) 
Lightening Detection 
Data: 1/min 

TDWR 


Wx-10 

Weather: 64 bits 

Weather: Negative 

Binomial 

Weather: 

Peak: 75 msqs/sec 
Busv (avq.): 15 msgs/sec 
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Automation/ 
Processing 
System (SINK) 

Sensors feeding into 
System (SOURCE) 

Traffic Model 

Traffic Type 

Data Attributes 

ATCT N EXRAD 
IDS 


Wx-5 

LLWAS Winds: 
800 bits 

LLWAS Threshold 
Winds: 2400 bits 

Uniform (constant) 
LLWAS Winds: 6/minute 
LLWAS Threshold 
Winds: 6/minute 

ATCT ACE 
Control Cabinet 


Wx-2, Wx-5 



Kavouris 

Receiver 


Wx-4, Wx-5 



AFSS Ml FC 

ARTCC FSDPS 

Wx-4, Wx-5 



FDP2000 

ARTCC FSDPS 

Wx-4, Wx-5 




Table B- 3: Flight Management Sensors/Systems 


Automation/ 
Processing 
System (SINK) 

Sensors feeding into 
System (SOURCE) 

Traffic Model 

Traffic Type 

Data Attributes 

ETMS (ARTCC) 

ETMCC, HOST 

N/A 



ETMCC (Volpe) 

ETMS 

T raffic 

management 
computer to 
ARTS/HCS 



CTAS/TMA 

HOST 

N/A 



pFAST 

CTAS/TMA 

N/A 



HOST/DSR 

CTAS/TMA, URET. CP 
DLC, ODAPS, OASIS, 
ARINC/AFTN, HOST, 
ARTS/STARS 

HCSto 

ARTS; 

ARTS/HCS to 
T raffic 

management 

computer 



URET CCLD 
(Conflict Probe) 

URET, HOST 

N/A 



AIS WS 

AIS Remote 

AIS database 
download 



FDIO Remote 
Control Unit 

HOST 

Flight Data 
Input, 
Flight Data 
Output 



Host (via FDSPS) 

HOST, DUAT/AFSS, 
FSDPS, MBO 

Aut-2 

Flight Data 
Acknowledgement: 
264 bits 

ALNOT and IREQ 
Cancellations: 328 
bits 

Flight Plan Closure: 
400 bits 

ICAO Departure: 
520 bits 

ALNOT and INREQ 
Responses: 928 
bits 

Flight Notification: 
1128 bits 
Flight Plan 
Disapprove: 2000 
bits 

ICAO Filed Flight 

Uniform (constant) 

Flight Data 

Acknowledgement: 1/hr 
ALNOT and IREQ 
Cancellations: 4/hr 
Flight Plan Closure: 
129/hr 

ICAO Departure: 5/hr 
ALNOT and INREQ 
Responses: 3/hr 
Flight Notification: 129/hr 
Flight Plan Disapprove: 
194/hr 

ICAO Filed Flight Plan: 
15/hr 

ALNOT and INREQ: 5/hr 
Automatic Alert 
Message: 100/hr 
ICAO Aerodrome and 
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WMSCR 


US Customs 


Oceanic SI R/TP 
Server 


NORAD TTY 


ODAPS 



ARINC/AFTN 


ARTCC 


HOST 


ODAPS 


OFDPS 


ARINC/SITA, DUAT/AFSS 
FSDPS 


Flight Data 
Input 


Flight Data 
Input, AUT-6 


AIDCS 


DOTS+ 


AWP 


ARINC/SITA 


ARINC/SITA, ETMCC 


Airlines 


Plan: 2304 bits 
ALNOT and 
INREQ: 6696 bits 
Automatic Alert 
Message: 80 bits 
ICAO Aerodrome 
and Radar 
Messages: 720 bits 
General Flight 
Service : 800 bits 
ICAO Synopses 
and Aircraft 
Reports: 720 bits 
General Information 
and Center 
Weather Advisory: 
1600 bits 
ICAO Terminal 
Forecast: 1600 bits 
ICAO Route and 
Area Forecasts: 
1600 bits 
ICAO Tabular 
Winds Forecast: 
2160 bits 
ICAO Weather 
Warning/Advisories: 
2400 bits 


Radar Messages: 84/hr 
General Flight Service : 
2/hr 

ICAO Synopses and 
Aircraft Reports: 71 /day 
General Information and 
Center Weather 
Advisory: 138/day 
ICAO Terminal Forecast: 
280/day 

ICAO Route and Area 
Forecasts: 4/day 
ICAO Tabular Winds 
Forecast: 28/day 
ICAO Weather 
Warning/Advisories: 
2/day 




Law Enforcement 
Alert Cancellation: 
824 bits 

Law Enforcement 
Alert: 1920 bits 
Law Enforcement 
Supplemental Alert: 
2384 bits 

Military Operations 
Message: 480 bits 
NOTAMS: 280 bits 
PIREPS: 720 bits 
Weather 
Information 
Requests: 800 bits 


DOD Surface 
Observations: 720 
bits 

PIREPS, ICAO 
Radar Reports & 
ICAO Aerodrome 
Reports: 720 bits 
Processed 
NOTAMS: 1040 bits 


Uniform (constant) 

Law Enforcement Alert 
Cancellation: 1/hr 
Law Enforcement Alert: 
1/hr 

Law Enforcement 
Supplemental Alert: 1/hr 
Military Operations 
Message: 3/hr 
NOTAMS: 5/hr 
PIREPS: 11/hr 
Weather Information 
Requests: 560/hr 


Uniform (constant) 
DOD Surface 
Observations: 165/hr 
PIREPS, ICAO Radar 
Reports & ICAO 
Aerodrome Reports: 
514/hr 

Processed NOTAMS: 
165/hr 
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AWOS Hourly 
Surface Wx 
Observation: 1600 
bits 

NWS Amendments: 
2700 bits 
NWS SIGMETS 
and AIRMETS: 

4800 bits 
NWS Surface 
Observations: 
39000 bits 
DOD Terminal 
Forecasts: 640 bits 
ICAO Aircraft 
Reports & 
Synopses: 720 bits 
Center Weather 
Advisory: 800 bits 
General Information 
& Meteorological 
Impact: 1600 bits 
ICAO Terminal 
Area Forecasts: 
1600 bits 
ICAO Route and 
Area Forecasts: 
1920 bits 
ICAO Tabular 
Winds Forecast: 
2160 bits 
ICAO Weather 
Warning/Advisories: 
2400 bits 
NWS 

Hurricane/Tropical 
Storm Advisory: 
6400 bits 
NWS Area 
Forecasts: 9600 
bits 

NWS Severe Wx 
Outlook: 12000 bits 
NWS Prognostic 
Map Discussion: 
22400 bits 
NWS Terminal 
Forecasts: 284000 
bits 
NWS 

Winds/Temperature 
Aloft Forecast: 
460000 bits 
Airport Reservation 
Data: 176 bits 
AWOS Special 
Surface Wx 
Observations: 1600 
bits 

DOD Hazardous 
Weather 

Information: 26400 


AWOS Hourly Surface 
Wx Observation: 905/hr 
NWS Amendments: 


NWS SIGMETS and 
AIRMETS: 5/hr 


Observations: 1/hr 


Forecasts: 660/day 
ICAO Aircraft Reports & 
Synopses: 812/day 
Center Weather 
Advisory: 69/day 
General Information & 
Meteorological Impact: 
138/day 

ICAO Terminal Area 
Forecasts: 280/day 
ICAO Route and Area 
Forecasts: 142/day 
ICAO Tabular Winds 
Forecast: 28/day 
ICAO Weather 
Warning/Advisories: 

1 1/day 

NWS Hurricane/Tropical 
Storm Advisory: 3/day 
NWS Area Forecasts: 
208/day 

NWS Severe Wx 
Outlook: 3/day 
NWS Prognostic Map 
Discussion: 4/day 
NWS Terminal 
Forecasts: 4/day 
NWS 

Winds/Temperature Aloft 
Forecast: 2/day 
Airport Reservation Data: 
1000/hr 

AWOS Special Surface 
Wx Observations: 10/hr 
DOD Hazardous 
Weather Information: 
2/day 

General Flight Service 
Message: 366/hr 
Law Enforcement Alert 
Cancellation: 5/hr 
Law Enforcement Alert: 


Law Enforcement 
Supplemental Alert: 5/hr 
Military Operations 
Message: 65/hr 
NWS Weather Warnings 
and Advisories: 1/hr 
Traffic Management 
Advisories: 15/hr 


107/hr 


NWS Surface 


DOD Terminal 


5/hr 









bits 

General Flight 
Service Message: 
800 bits 

Law Enforcement 
Alert Cancellation: 
720 bits 

Law Enforcement 
Alert: 1840 bits 
Law Enforcement 
Supplemental Alert: 
2300 bits 

Military Operations 
Message: 480 bits 
NWS Weather 
Warnings and 
Advisories: 5600 
bits 

Traffic Management 
Advisories: 5000 


STARS display 

pFAST 




ARTS/STARS 

HOST 

ARTS to HCS 



TRACON EFSTS 

ATCT EFSTS 

N/A 



TRACON DSP 

ATCT DSP 

N/A 



ARINC/SITA 

ATCT TDLS (PDC) 

N/A 



ATCT TDLS 
(FDIO simulator) 

ARINC/SITA, FDIO 

N/A 



AMASS (TAIU) 

ARTS 

N/A 



DOTS+ 

(ATCSCC) 

DOTS (Oceanic) 

N/A 



AFSS Ml FC 
Briefing Station 

FSDPS 

N/A 




Table B- 4: Aeronautical Systems/Sensors 


Automation/ 
Processing 
System (SINK) 

Sensors feeding into 
System (SOURCE) 

Traffic Model 

Traffic type 

Data Attributes 

WMSCR 

CNS 




AWP 

WMSCR 




FSDPS 

AWP, CNS 

Aut-3 

DOD Surface 

Uniform (constant) 




Observations: 720 

DOD Surface 




bits 

Observations: 165/hr 




PIREPS, ICAO 

PIREPS, ICAO Radar 




Radar Reports & 

Reports & ICAO 




ICAO Aerodrome 

Aerodrome Reports: 




Reports: 720 bits 

514/hr 




Processed 

Processed NOTAMS: 




NOTAMS: 1040 bits 

165/hr 




AWOS Hourly 

AWOS Hourly Surface 




Surface Wx 

Wx Observation: 905/hr 




Observation: 1600 

NWS Amendments: 




bits 

107/hr 




NWS Amendments: 

NWS SIGMETS and 




2700 bits 

AIRMETS: 5/hr 




NWS SIGMETS 

NWS Surface 




and AIRMETS: 

Observations: 1/hr 




4800 bits 

DOD Terminal 




NWS Surface 

Forecasts: 660/day 




Observations: 

ICAO Aircraft Reports & 
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Automation/ 
Processing 
System (SINK) 

Sensors feeding into 
System (SOURCE) 

Traffic Model 

Traffic type 

Data Attributes 




39000 bits 
DOD Terminal 
Forecasts: 640 bits 
ICAO Aircraft 
Reports & 
Synopses: 720 bits 
Center Weather 
Advisory: 800 bits 
General Information 
& Meteorological 
Impact: 1600 bits 
ICAO Terminal 
Area Forecasts: 
1600 bits 
ICAO Route and 
Area Forecasts: 
1920 bits 
ICAO Tabular 
Winds Forecast: 
2160 bits 
ICAO Weather 
Warning/Advisories: 
2400 bits 
NWS 

Hurricane/Tropical 
Storm Advisory: 
6400 bits 
NWS Area 
Forecasts: 9600 
bits 

NWS Severe Wx 
Outlook: 12000 bits 
NWS Prognostic 
Map Discussion: 
22400 bits 
NWS Terminal 
Forecasts: 284000 
bits 
NWS 

Winds/Temperature 
Aloft Forecast: 
460000 bits 
Airport Reservation 
Data: 176 bits 
AWOS Special 
Surface Wx 
Observations: 1600 
bits 

DOD Hazardous 
Weather 

Information: 26400 
bits 

General Flight 
Service Message: 
800 bits 

Law Enforcement 
Alert Cancellation: 
720 bits 

Law Enforcement 

Synopses: 812/day 
Center Weather 
Advisory: 69/day 
General Information & 
Meteorological Impact: 
138/day 

ICAO Terminal Area 
Forecasts: 280/day 
ICAO Route and Area 
Forecasts: 142/day 
ICAO Tabular Winds 
Forecast: 28/day 
ICAO Weather 
Warning/Advisories: 

1 1/day 

NWS Hurricane/Tropical 
Storm Advisory: 3/day 
NWS Area Forecasts: 
208/day 

NWS Severe Wx 
Outlook: 3/day 
NWS Prognostic Map 
Discussion: 4/day 
NWS Terminal 
Forecasts: 4/day 
NWS 

Winds/Temperature Aloft 
Forecast: 2/day 
Airport Reservation Data: 
1000/hr 

AWOS Special Surface 
Wx Observations: 10/hr 
DOD Hazardous 
Weather Information: 
2/day 

General Flight Service 
Message: 366/hr 
Law Enforcement Alert 
Cancellation: 5/hr 
Law Enforcement Alert: 
5/hr 

Law Enforcement 
Supplemental Alert: 5/hr 
Military Operations 
Message: 65/hr 
NWS Weather Warnings 
and Advisories: 1/hr 
Traffic Management 
Advisories: 15/hr 
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Automation/ 
Processing 
System (SINK) 

Sensors feeding into 
System (SOURCE) 

Traffic Model 

Traffic type 

Data Attributes 




Alert: 1840 bits 
Law Enforcement 
Supplemental Alert: 
2300 bits 

Military Operations 
Message: 480 bits 
NWS Weather 
Warnings and 
Advisories: 5600 
bits 

Traffic Management 
Advisories: 5000 


Ml FC 

FSDPS 




ISD4 or ACE/ISD 

NOTAM Distribution Client 




NOTAM 

Distribution Client 
(NAIMES WS) 

USNS Distribution Server 




SAMS Client 

SAMS Server 




SAMS Server 

SAMS Client 




ODAPS 

WMSCR 




USNS 

Distribution 

Server 

NOTAM Distribution Client 




Consolidated 
NOTAM System 
(CNS) 

FSDPS, OASIS 




ATCT/TRACON 
Phone /fax 

AFSS Phone/Fax 





Table B- 5: Resource Management Systems/Sensors 


Automation/ 
Processing System 
(SINK) 

Sensors feeding into System 
(SOURCE) 

Traffic Model 

Traffic type 

Data Attributes 

RMS Module 

MPS 

RMS to MPS 



MPS 

RMS, MDT, MPS 

MPS to RMS 
MPS to MPS 



NIMS Management 
Console 

RMVC 




Remote Monitoring 
VORTAC Concentrator 

NIMS Management Console 
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APPENDIX C: Basics of the NAS 


The Basics: 

When you fly in the United States, you take it for granted that you will fly safely from place to 
place. What makes that possible? 

Most people are familiar with the airport. They arrive and check in their baggage and 
themselves. They board the airplane and then sit back, relax and enjoy the ride. 

Passengers arrive safely at their destinations, on time and ready to begin the next leg of their 
journey. They claim their baggage and leave the airport. 

So what makes this happen? The NAS helps to make this happen. So what exactly is the NAS. 

The NAS is a collection of systems, used by people, following certain procedures. 

Passengers tend to experience only a small part of the total system, the airport. The airport is 
the most obvious part of the NAS. It visibly represents the hustle and bustle of the entire 
system. People and things moving from place to place. 

(Back to top) 


How does your Flight Work? 



Ground Operations: 
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When you board an airplane, it is located on the ramp of an airport. This is the ground part of 
the NAS. 

Air Traffic Control Tower: 

The flight is under the supervision of the Air Traffic Control Tower until it is about 5 miles from 
the runway. The tower is the most recognized symbol of the NAS. The tower controllers are 
located in the glass booth you see at an airport at the top of the tower. When the pilot taxis the 
aircraft to the runway and departs the airport, the airborne part of the flight begins. 

Departure: 

Once the airplane is five miles beyond the airport, the control of the plane is transferred to the 
Terminal Radar Approach Control Facility (or TRACON). The TRACONs sequence and 
separate aircraft as they approach major metropolitan areas. There are over 185 TRACONs in 
the United States. TRACONs provide air traffic control services from just outside the airport to 
about 40 miles away. 

Controllers and pilots are in constant communication. The controllers instruct the pilots on safe 
altitude, course and speeds to avoid other aircraft. Terminal controllers work with pilots to 
ensure the flight path is smooth and free of other traffic. The pilots acknowledge these 
directions and maneuver the airplanes safely. 

En Route Airspace: 

For most commercial flights, when the airplane departs the terminal airspace it enters the en 
route airspace. The way pilots get from one place to another is by highways, known as routes, 
in the sky. Some routes are primarily north and south, others run east to west. Various routes, 
or lanes, operate at different altitudes. 

Twenty Air Route Traffic Control Centers (or ARTCCs) control and monitor airplanes over the 
continental United States and between airports. En route airspace extends beyond the United 
States coastline by approximately 100 miles and is bordered on the north by Canada and 
Mexico to the south. En route controllers work with pilots to ensure the flight path is smooth and 
free of other traffic. 

Oceanic Control: 

For flights over the ocean, United States controllers control the operations over part of the 
Atlantic, Pacific, and Arctic Oceans. These operations are very different from controlling aircraft 
over land. Once outside radar range, controllers must rely on periodic radio communications of 
position reports to determine the aircraft's location. The United States is responsible for almost 
80 percent of the world's controlled oceanic airspace. 

Arrival: 

When a flight is approaching the airport, it descends from the en route or oceanic airspace into 
terminal airspace, where the TRACON controller efficiently sequences the airplane toward the 
runway. The tower controller ensures that the runway is clear for landing, the ground controller 
issues the instructions to get to the ramp where the ramp operators ensure the aircraft is quickly 
moved to the proper gate. 

Flow Management: 

Monitoring the entire operation is the David J. Hurley Air Traffic Control System Command 
Center ATCSCC), located in Herndon, Virginia. They receive an electronic picture of flights in 
the NAS from the ARTCCs across the country. The ATCSCC is responsible for ensuring the 
efficient use of all NAS resources through interaction with the FAA control facilities and airline 
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operations centers. This interaction allows the ATCSCC to develop guidelines, such as 
arrival/departure restrictions or alternative routings, to ensure that the operation of the NAS 
remains efficient. The exchange of information consists of equipment outages, congestion 
areas, and weather information to allow everyone including the users to participate in a 
collaborative decision making process for operating the NAS. 

Airport: 

There are about 3,300 airports in the United States that are considered significant to the 
capacity of the NAS. 41 3 of these airports are considered primary airports. These primary 
airports handle the vast majority of scheduled commercial flights. Each primary airport sees 
more than ten thousand passengers annually. The top 100 airports saw well over 500 million 
passengers in 1997 alone. 

There are over 600,000 active pilots operating more than 280,000 aircraft. Aircraft include: 

• commercial airplanes that carry people and cargo, 

• small airplanes used by private pilots, 

• helicopters, including those that are used for medical evacuation operations, 

• business jets, and 

• balloons and other craft. 

Almost 30,000 FAA employees are actively involved with the monitoring and control of aircraft 
through the NAS. All these people, working together, result in safe, secure, and efficient flights. 

(Back to top) 


What makes the NAS work? 

In each piece of airspace, many pieces of equipment must operate in harmony. 

Navigational aids provide location signals to pilots. 
Each domain, or type of airspace, has unique 
requirements for precision. The accuracy needed to 
land in poor weather conditions is demanding. 
During the en route portion of a flight, navigational 
accuracy, although important, can be less precise. 


The current NAS is based on a number of fixed 
routes, or highways in the sky. These routes are 
directly related to the ground-based navigational 
aids available to the pilot. 

The western portion of United States has benefited from the removal of restrictions, which were 
based on these routes. Airplanes can now request direct (point-to-point) routes between certain 
locations. East of the Mississippi, there are more airplanes flying at any given time due to the 
proximity of major hubs to one another (for example, Philadelphia to New York, Washington to 
New York, Washington to Boston, etc.). Better accuracy of positions to both the controllers and 
pilots is required to safely ensure the removal of restrictions and allow more direct flights. 
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In an age where the Global Positioning System 
(GPS) is available for our cars, we should be using it 
for aviation as well. The currently approved 
navigational aids of the NAS do not take full 
advantage of GPS. The NAS, while very good, can 
be improved and flights can be made even safer 
through the use of augmented GPS. 

Without radios, controllers and pilots would not be 
able to verbally communicate. On many flights, 
passengers can listen to the pilots and controllers. As 
the aircraft moves from one domain to another or 
from one sector to another, a new controller becomes 
responsible to monitor and control the flight. A sector (volume of airspace) is like county lines on 
a map extended upward in the sky. Each controller has the responsibility for the activity within 
one sector. 

The current radios are based on the 1960's technology. Controllers and pilots can communicate 
some information without voice communications (initial clearance information, Pre-departure 
Clearance). Over the Pacific Ocean, we have established some non-verbal real time 
communication links, called Oceanic Data Link. However, most oceanic communications are 
relayed through a third person rather than using satellite technology. 

There is no radar coverage over the ocean. Pilots must report their positions verbally or have 
them automatically sent through a relay station. The automation system acts like a big 
calculator and displays the position of the aircraft to the controllers. Because of the delays 
imposed by relaying communications, it is hard to accommodate requests for route and altitude 
changes over the ocean. 




Oceanic Services Safely Meet Future Demand for Flights to Europe, Asia and the Pacific Rim 



Surveillance or position information is processed by 
computers and displayed to the controllers on large 
computer screens. New tools to help the controllers 
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move more aircraft safely through the system have been developed. After years of research, 
these tools are now installed into some of the air traffic control facilities. 

The controllers use automation tools (displays with computer processors and aviation software) 
to assist them with the tracking of aircraft. The aircraft submits a flight plan prior to take off. The 
automation systems monitor the progress of the flight with the radar information. The controller 
knows where the aircraft is located as well as where the aircraft is heading. 

The current NAS is aging. Automation 
advances in recent years have been amazing. 

The enroute mainframe computers and the 
display system are being replaced now. All the 
terminal automation equipment is scheduled to 
be replaced. These older systems are not 
capable of accepting the new tools controllers 
need. Therefore these systems must be 
replaced. 


Likewise, our telecommunication circuits have 
limited capacity and use old technology. These 
to meet demand for increased capacity. 

Most NAS facilities were built in the 1950's. Some have been renovated. Many, though, need 
repair. Roofs leak. The power supply within the facility is unreliable. The buildings are too small. 
Access control is not compliant with federal law. Security is not adequate. 

(Back to top) 



systems must be upgraded or replaced in order 


What is being done to improve the NAS? 

NAS Modernization has three key categories. The first category focuses on upgrading the 
infrastructure. The second category focuses on providing new safety features. The third 
category introduces new efficiency-oriented capabilities into the existing system. All the efforts 
associated with these three categories must be integrated. The evolution to a modernized NAS 
must be well orchestrated and balanced with the resources available. 

New safety and efficiency capabilities require new 
tools and procedures, as well as training for 
controllers and pilots. But for the new tools to work 
efficiently, the infrastructure must be sound. This 
infrastructure includes buildings to securely and 
safely house the processors and displays for the 
controller. It also includes radar and radios. For the 
terminal area and many of the towers, STARS ( the 
Standard Terminal Automation Replacement 
System,) is the key to the future. STARS will 
replace the displays and processors. It will provide 
a solid foundation for new capabilities. 

For STARS to work successfully at many of the facilities it will be necessary to upgrade power 
systems and communication systems within the facility. Some facilities must be modified to be 
brought up to current standards for safety and security. In a few cases, structural repairs must 
be made before STARS can become operational. 
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Like our nation's highways, the facilities in the NAS are aging. Many of the Towers, TRACONs 
and ARTCCs need to be upgraded to meet current standards. OSHA standards, earthquake 
standards, power standards, and others have changed in the past 30 years. It is time for many 
of these significant repairs and upgrades to be accomplished at facilities housing our air traffic 
controllers. 


Many facilities in the NAS house radios or other equipment. These too may need new roofs, 
more reliable or "cleaner" power, or a host of other facility modifications. It is crucial that we 
keep our NAS systems protected. Lost radar or communications signals can slow the flow of 
aircraft to a busy city. This may cause delays throughout the entire region, or possibly the whole 
country. 


The second category for modernization activities 
focuses on the upgrades for safety. 

Weather has a big impact on the NAS. Fog in San 
Francisco, snow in Denver, thunderstorms in Kansas, 
wind in Chicago; all these reduce the safety and 
capacity of the NAS. Although we cannot control the 
weather, we are making great strides in being able to 
predict the weather. Controllers are receiving better 
information about winds and storms. The pilots are 
receiving better information before they take-off. All 
this makes flying safer. 




This improved accuracy helps the pilots 
know their positions, which increases safety of flight. WAAS also enables improvements in 
efficiency, by providing access to more runways in poor weather, due to the precise navigation 
service it provides. 


Another cornerstone of the future for the 
FAA is improved navigational information 
available in the cockpit. The use of GPS 
will become more widely accepted. The 
Wide Area Augmentation System (or 
WAAS) will supplement GPS and provide 
pilots the accuracy they need for most 
flights. 


The Local Area Augmentation system (or LAAS) is being developed to provide even better 
accuracy than either GPS alone, or GPS with WAAS. LAAS will provide localized service for 
final approaches in poor weather conditions at major airports. Airports that require LAAS will be 
most of the top 1 00 airports in the United States and a few selected other locations that need 
the local signal due to other technical reasons. 


This additional navigational accuracy that will be available in the cockpit will be used for other 
system enhancements. The Automatic Deptly (??) being evaluated by the FAA and airlines, 
takes advantage of this improved accuracy. 
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The ADS system will allow the aircraft to 
automatically transmit or "squitter" its location 
to various receivers. This "squitter" or 
broadcast mode is commonly referred to as 
ADS-B. The ADS-B signal can be received by 
other properly equipped aircraft. It also can be 
heard on the ground by receiver stations. The 
ground stations can then feed the automation 
system accurate aircraft position information. This more accurate information will be used to 
improve the efficiency of the system and is related to the third category of modernization 
activities. 

New Procedures & Equipment Promote Fuel Efficient Flights 

Other key efficiency improvements will be found in the deployment of new tools to assist the 
controller. 

Over the ocean, most commercial aircraft already have equipment to send their GPS positions 
automatically to receiver stations. This is the key enhancement needed in all the oceanic 
airspace to allow more efficient use of airspace. 


Improving text and graphical message 
exchange is the ultimate goal of the Controller 
Pilot Data Link Communications (CPDLC) 
Program. The first step is CPDLC Build 1 . This 
step allows the FAA and pilots to understand 
how roles and responsibilities can change 
based on the increased exchange of 
information. This step will be conducted at Miami, and although the field test is still a few years 
off, preparations are under way by both the FAA and American Airlines. 

In the en route domain, DSR, the Display System Replacement, along with the Host/Oceanic 
Computer System Replacement, HOCSR, and Eunomia projects, are the platforms and 
infrastructure for the future. These provide new displays to the controllers and upgrade the 
computers to accept future tools, and provide modern surveillance and flight data processing 
capabilities. For CPDLC to work effectively, it must be integrated with the en route controllers' 
workstation. 

We have begun to implement tools requested by the 
users through a project called Free Flight Phase 1. 

The National Civil Aviation Review Commission 
warned of impending gridlock at many of our major 
airports. Airlines say they will run into difficulties 
scheduling their flights without undue delays as early 
as 2005. We must expand airspace capabilities to 
meet growing demand. 

More than preventing gridlock, Free Flight Phase 1 provides the incremental steps the FAA 
needs to take to modernize the National Airspace System. There are five tools associated with 
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Free Flight Phase 1 . 


The User Request and Evaluation Tool (URET) is 
designed to help en route controllers predict the 
future flight path and identify potential conflicts. This 
tool helps controllers to allow planes to deviate from 
filed routes to avoid poor weather or to take 
advantage of favorable winds. 


Another tool to be used in the ARTCC is called 
Traffic Management Advisor (or TMA). This tool assists traffic management specialists with 
developing arrival sequence plans for selected airports. Currently this tool is effective at airports 
that receive airplanes from one ARTCC. 



Both URET and TMA will provide key 
improvements and are being implemented on a 
limited scale. These tools will help the aircraft 
fly a more direct route from point to point. And, 
both of these tools operate on the new en route 
displays. 

Improved Transition Between Airspace En 
Route and Terminal Airspace 
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Another key set of tool to ensuring that aircraft can arrive at their destination on time is 
Collaborative Decision-Making. 


Collaborative Decision-Making, (known as 
CDM,) provides airline operation centers with 
real time access to information about the status 
of the NAS. This includes information about 
weather, equipment status, and known delays. 
With this information, the airlines, are able to 
better anticipate "trouble spots" and start to 
prepare contingency plans. Although this may 
not prevent a passenger from being delayed by 
poor weather at their destination, it does help airlines avoid stranding passengers and 
airplanes. 

Improving operations around the airport is critical to most major airlines. Two tools are currently 
being tested to improve traffic flow around the airport. Both of these tools work with the Terminal 
Automation systems. 

The first tool, pFAST (the passive final 
approach spacing tool) is used at the 
TRACON. It helps controllers sequence aircraft 
and assign runways based on user preferences 
and airport constraints. 






Sharing of information is very important to the 
improvement of NAS operations. The second 
tool to improve operations near the airport 
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increases the sharing of information between the FAA and the airlines and is called SMA (or 
Surface Movement Advisor). The purpose of this tool is to provide information about arriving 
and departing aircraft to the airlines. Information, such as identifying the runway and the 
sequence for landing, enables the airline to plan better. This is most critical at hub airports when 
airplane turn-around times at the gate are closely scheduled. 



APPENDIX D: Definitions 

Air Vehicle Control Station (AVCS) - A site configured to allow a pilot in command of 
an ROA to operate and monitor all ROA operations conducted under his or her authority. 

ATC Communications Link - Two-way data or voice link between the ROA system and 
the ATC system and/or other aircraft. 

Command and Control (C2) Link - Two-way data link between the ROA pilot and the 
ROA that is used to control and monitor the health and status of the ROA. 

High Altitude Long Endurance (HALE) ROA - An ROA capable of performing the 
mission objectives at an altitude of 40,000-foot mean sea level (MSL) or higher with 
sufficient cruise capability to transit the NAS. 

Line of Sight (LOS) - The condition where the path between the air vehicle control 
station and the ROA form an unobstructed straight line. 

Over the Horizon (OTH) - The condition where the air vehicle control station and the 
ROA are beyond line of site from each other. 

Remotely Operated Aircraft (ROA) - An aircraft that is operated from a remote location 
by an operator that issues command and control instructions to the aircraft, which are 
executed near real-time by an onboard autonomous flight management control system. 


1 



APPENDIX E: Acronyms 


ACAS 

ADLS 

ADS-B 

CDM 

C4ISR 

CPDLC 

DODAF 

EGPWS 

FIS-B 

FEAF 

FDR 

FOC 

FOMS 

GPWS 

IEC 

ISO 

IMG 

OEP 

RNAV 

RNP 

SDN 

SWIM 

TAWS 

TCAS 

TIS-B 

TMC 

TSD 

VMC 


Airborne Collision Avoidance System 

Airborne Dependent Surveillance-Broadcast 
Collaborative Decision Making 

Command, Control, Communications, Computers, Information, 

Surveillance, Reconnaissance 

Controller Pilot Data Link Communication 

Department of Defense Architecture Framework 

Enhanced Ground Proximity Warning System 

Flight Information Service-Broadcast 

Federal Enterprise Architecture Framework 

Federal Data Registry 

Flight Operations Center 

Flight Object Management System 

Ground Proximity Warning System 

International Electrotechnical Commission 

International Standards Organization 

Instrument Meteorological Conditions 

Operational Evolution Plan 

Area Navigation 

Required Navigation Performance 
Surveillance Data Network 
System Wide Information Management 
Terrain Avoidance Warning System 
Traffic Collision Avoidance System 
Traffic Information System-Broadcast 
Traffic Management Coordinator 
Target System Description 
Visual Meteorological Conditions 
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